info symbol in gdb

This is a discussion on info symbol in gdb within the C++ Programming forums, part of the General Programming Boards category; Hi,
I am learning to use "info symbol <address>" in gdb. here is my code:
Code:
#include <iostream>
#include "functions.h"
...

Assuming my program has segment fault and stops in gdb, isn't the address shown by backtrace the memory address? How to do if I want to know what variable (usually local non-static) is using the memory address?

Assuming my program has segment fault and stops in gdb, isn't the address shown by backtrace the memory address? How to do if I want to know what variable (usually local non-static) is using the memory address?

Thanks and regards!

A memory address, but a memory address of code, not a variable (unless I am grossly misunderstanding what you mean). And generally gdb will show you that line if it's available.

EDIT: For example, you might get something like this:

Code:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x00001e29 in main () at symbols.c:9
9 cout << *foo << endl;

The 0x00000000 is the value of foo in the sample line, not where foo is stored. The 0x00001e29 is where my code is, and that specific line is given to me.

Thank you, tabstop!
1. does the symbol generated with gdb -g only for global or static variables, not for local nonstatic variables?
2. Given an address, is it possible to know the local variable that is using it?
3. when analyzing the place where segment fault happens, Is it possible to find out the memory address whose access causes the runtime error?
Thanks!

Thank you, tabstop!
1. does the symbol generated with gdb -g only for global or static variables, not for local nonstatic variables?
2. Given an address, is it possible to know the local variable that is using it?
3. when analyzing the place where segment fault happens, Is it possible to find out the memory address whose access causes the runtime error?
Thanks!

1. info frame and info locals gives you some information, and you can probably piece things together from there if you have to.
2. I can't think of a way off the top of my head. I can also not dream up a scenario in which such thing is even a little bit useful, so I admit I didn't work very hard at it. (Apart from going down the list in info locals and finding the address of each.)
3. Given that gdb tells you straight up when such a thing happens, I would say "yes". Did you look at the edit I put in last time?

for 3, I meant the memory address for a variable not for the code line.

But now I think if I could know the line of code that directly causes the problem, the variable whose memory access causes the problem must be used by the line of code. And then look around nearby variables stored around that variable, I could locate the actual reason that causes the runtime error. Is this the right way to solve the memory runtime error?

for 3, I meant the memory address for a variable not for the code line.

But now I think if I could know the line of code that directly causes the problem, the variable whose memory access causes the problem must be used by the line of code. And then look around nearby variables stored around that variable, I could locate the actual reason that causes the runtime error. Is this the right way to solve the memory runtime error?

Yes I see.
As to looking around that variable, I meant in some cases when I write out of the boundary of an array, runtime error occurs not at that place but several lines later where a nearby variable is affected and triggers the error. So l think it might help to look around.

Yes I see.
As to looking around that variable, I meant in some cases when I write out of the boundary of an array, runtime error occurs not at that place but several lines later where a nearby variable is affected and triggers the error. So l think it might help to look around.

Perhaps. If you do that commonly, you should look at doing bounds-checking rather than waiting for a run-time error.