I use print (CEthPacket*) 0xeb609a0 to examine an object at the given address and get A syntax error in expression, near ') 0xeb609a0'.
What am I doing wrong?
EDIT:
CEthPacket is a C++ class and I'm on gdb Fedora (6.8-37.el5).
I just ran in to similar issue, and, from a colleague of mine, I learnt that you need to provide the namespace that the class belongs to within a single quotes as following:
(gdb) p ('MyScope::MyClass'*) ptr;
You didn't say on which platform, which version of GDB, or what CEthPacket is.
My first guess is that you should try print (struct CEthPacket *) 0xeb609a0 instead.
Also your starting namespace is the one from current stack. If you want to start from root you have to use ::NS1::NS2::Obj.
I just ran into a very similar error. It was caused because I was trying to reference an object that is not defined in the scope of the current stack frame. Try changing to a stack frame where the CEthrPacket object is defined.
Related
I'm working with a C++ library. The library uses several namespaces. When debugging, I have to prefix every symbol name with the namespace prefix. It causes a lot of extra work and typing.
C++ has the using namespace X concept to make symbols available with more ease (lots of hand waiving). I'm looking for similar in GDB. For example, instead of b MyLibNamespace::Foo::bar, I want to b Foo::bar.
GDB does not appear to have help related to namespaces, but I'm probably doing something wrong:
(gdb) help namespace
Undefined command: "namespace". Try "help".
(gdb) namespace help
Undefined command: "namespace". Try "help".
How do I tell GDB to use a namespace prefix so I don't have to provide it for every symbol name?
How do I tell GDB to use a namespace prefix so I don't have to provide it for every symbol name?
There doesn't appear to be any such support in current GDB (as of 2017-08-13).
You can probably implement it using Python scripting to define a new command. Documentation.
Beware, this is entirely non-trivial proposition.
How do I tell GDB to use a namespace prefix so I don't have to provide
it for every symbol name?
You might consider a work-around...
I have (on occasion) added one or more (C++) functions to my class definitions file. (.cc), but they are not part of the class(s).
They are not part of the application, and are harmlessly removed when you are done with them.
They generally 'dump' info (with names d1(), d2(), etc.)
But they can also do practically any thing useful for your debugging effort, Usually, it is not the case that you thought of this specific test effort ahead of time.
So, your edit/compile/link iteration is simply: stop gdb, open the file, add a useful function, line, and resume gdb. Keep this 'diagnostic' code simple. Hopefully the result is ultimately time saving.
I can find no examples (in my files) at the moment. I suppose I discard these functions quickly once I've overcome a particular challenge.
Anyway ... this demo worked just a few minutes ago ...
When working in gdb near my class Foo_t, part of namespace DTB, etc. the d1 I've created knows how to access a particular instance of Foo_t (in some convenient way), and, can easily dump the current state of the instance using a Foo method to do so. Perhaps d1 can look like this:
void d1() { objDer.f("xxx"); } // a derived instance,
// the class has a long complex name.
Now, in gdb, run to a breakpoint somewhere when that instance exists, and is initialized, and use gdb print command to run d1 ...
(gdb) p d1()
that is a short gdb command to get at the instance and run a method.
0x004069f1 in Space::setPosition (this=0x77733cee, x=-65, y=-49) at space.h:44
0x00402679 in Checkers::make_move (this=0x28cbb8, move=...) at checkers.cc:351
0x00403fd2 in main_savitch_14::game::make_computer_move (this=0x28cbb8) at game.cc:153
0x00403b70 in main_savitch_14::game::play (this=0x28cbb8) at game.cc:33
0x004015fb in _fu0___ZSt4cout () at checkers.cc:96
0x004042a7 in main () at main.cc:34
Hello, I am coding a game for a class and I am running into a segfault. The checker pieces are held in a two dimensional array, so the offending bit appears to be invalid x/y for the array. The moves are passed as strings, which are converted to integers, thus for the x and y were somehow ASCII NULL. I noticed that in the function call make_move it says move=...
Why does it say move=...? Also, any other quick tips of solving a segfault? I am kind of new to GDB.
Basically, the backtrace is trace of the calls that lead to the crash. In this case:
game::play called game::make_computer_move which called Checkers::make_move which called Space::setPosition which crashed in line 44 in file space.h.
Taking a look at this backtrace, it looks like you passed -65 and -49 to Space::setPosition, which if they happen to be invalid coordinates (sure look suspicious to me being negative and all). Then you should look in the calling functions to see why they have the values that they do and correct them.
I would suggest using assert liberally in the code to enforce contracts, pretty much any time you can say "this parameter or variable should only have values which meet certain criteria", then you should assert that it is the case.
A common example is if I have a function which takes a pointer (or more likely smart pointer) which is not allowed to be NULL. I'll have the first line of the function assert(p);. If a NULL pointer is ever passed, I know right away and can investigate.
Finally, run the application in gdb, when it crashes. Type up to inspect the calling stack frame and see what the variables looked like: (you can usually write things like print x in the console). likewise, down will move down the call stack if you need to as well.
As for SEGFAULT, I would recommend runnning the application in valgrind. If you compile with debugging information -g, then it often can tell you the line of code that is causing the error (and can even catch errors that for unfortunate reasons don't crash right away).
I am not allowed to comment, but just wanted to reply for anyone looking more recently on the issue trying to find where the variables become (-65, -49). If you are getting a segfault you can get a core dump. Here is a pretty good source for making sure you can set up gdb to get a core dump. Then you can open your core file with gdb:
gdb -c myCoreFile
Then set a breakpoint on your function call you'd like to step into:
b MyClass::myFunctionCall
Then step through with next or step to maneuver through lines of code:
step
or
next
When you are at a place in your code that you'd like to evaluate a variable you can print it:
p myVariable
or you can print all arguments:
info args
I hope this helps someone else looking to debug!
I have a function that returns a pointer:
static void *find_fit(size_t asize);
I would like to set a breakpoint in gdb, but when I type this function name, I get one of these errors:
break *find_fit
Function "*find_fit" not defined
or
break find_fit
Function "find_fit" not defined
I can easily set break point on a function that returns something other than a pointer, but when the function does return a pointer, gdb doesn't seem to want to break on it.
Anybody see what is going on? Thanks!
It sounds like for some reason, gdb isn't handling C++ name mangling correctly. Normally you don't have to touch anything for this to work. You can try show language. Typically it's set to auto. You can also try manually setting it with set language c++.
To test, you can just type
b 'find<tab>
(that's the tab character, not the characters "<tab>") and it should try to autocomplete the name of the function for you. In C++ you need the argument types to know the function, but that doesn't 100% fit with what you're seeing because if you give gdb a function name without arguments, it'll usually do the right thing or prompt you for which version of a function you want. You aren't seeing either of those.
I got a working program compiled with gcc 3.44 but when I compiled it again using 4.44 there's something wrong. Some of the local variables in a function seems to be modified by unknown so that a for loop will not terminate because variable in its condition is constantly changing to 0 even if it's incremented. Calling a function under the loop seems to be okay because it returned to a correct address. I tried tracing the value of the variable in which the loop is affected, I found out the the value is modified after calling a print function under an if branch, removing or adding more print call solves it but I think it has nothing to do with the print function and there's no code that modify that variable except only the increment in the loop. I also tried tracing esp at the beginning and end of the loop, it is the same. What could have caused the problem?
You stated that you're going from GCC v3.44 (where the code works) to v4.44 where the code is broken.
Make sure that all other parts of the program (all source files and library files) are also compiled with GCC v4.44. You're calling a print function, so I'm guessing you're referring to the standard printf function in glibc. So make sure that glibc is also compiled under v4.44.
If this is really a problem with your print functions, maybe you are corrupting the stack with some of the parameters of the variadic list? Maybe an assumption that you had about one of the standard data types or enumeration constants doesn't hold any more? Are these your own print functions? Then try to use the __attribute__ extension of gcc to have compile time type checks.
My executable contains symbol table. But it seems that the stack trace is overwrited.
How to get more information out of that core please? For instance, is there a way to inspect the heap ? See the objects instances populating the heap to get some clues. Whatever, any idea is appreciated.
I am a C++ programmer for a living and I have encountered this issue more times than i like to admit. Your application is smashing HUGE part of the stack. Chances are the function that is corrupting the stack is also crashing on return. The reason why is because the return address has been overwritten, and this is why GDB's stack trace is messed up.
This is how I debug this issue:
1)Step though the application until it crashes. (Look for a function that is crashing on return).
2)Once you have identified the function, declare a variable at the VERY FIRST LINE of the function:
int canary=0;
(The reason why it must be the first line is that this value must be at the very top of the stack. This "canary" will be overwritten before the function's return address.)
3) Put a variable watch on canary, step though the function and when canary!=0, then you have found your buffer overflow! Another possibility it to put a variable breakpoint for when canary!=0 and just run the program normally, this is a little easier but not all IDE's support variable breakpoints.
EDIT: I have talked to a senior programmer at my office and in order to understand the core dump you need to resolve the memory addresses it has. One way to figure out these addresses is to look at the MAP file for the binary, which is human readable. Here is an example of generating a MAP file using gcc:
gcc -o foo -Wl,-Map,foo.map foo.c
This is a piece of the puzzle, but it will still be very difficult to obtain the address of function that is crashing. If you are running this application on a modern platform then ASLR will probably make the addresses in the core dump useless. Some implementation of ASLR will randomize the function addresses of your binary which makes the core dump absolutely worthless.
You have to use some debugger to detect, valgrind is ok
while you are compiling your code make sure you add -Wall option, it makes compiler will tell you if there are some mistakes or not (make sure you done have any warning in your code).
ex: gcc -Wall -g -c -o oke.o oke.c
3. Make sure you also have -g option to produce debugging information. You can call debugging information using some macros. The following macros are very useful for me:
__LINE__ : tells you the line
__FILE__ : tells you the source file
__func__ : tells yout the function
Using the debugger is not enough I think, you should get used to to maximize compiler ablity.
Hope this would help
TL;DR: extremely large local variable declarations in functions are allocated on the stack, which, on certain platform and compiler combinations, can overrun and corrupt the stack.
Just to add another potential cause to this issue. I was recently debugging a very similar issue. Running gdb with the application and core file would produce results such as:
Core was generated by `myExecutable myArguments'.
Program terminated with signal 6, Aborted.
#0 0x00002b075174ba45 in ?? ()
(gdb)
That was extremely unhelpful and disappointing. After hours of scouring the internet, I found a forum that talked about how the particular compiler we were using (Intel compiler) had a smaller default stack size than other compilers, and that large local variables could overrun and corrupt the stack. Looking at our code, I found the culprit:
void MyClass::MyMethod {
...
char charBuffer[MAX_BUFFER_SIZE];
...
}
Bingo! I found MAX_BUFFER_SIZE was set to 10000000, thus a 10MB local variable was being allocated on the stack! After changing the implementation to use a shared_ptr and create the buffer dynamically, suddenly the program started working perfectly.
Try running with Valgrind memory debugger.
To confirm, was your executable compiled in release mode, i.e. no debug symbols....that could explain why there's ?? Try recompiling with -g switch which 'includes debugging information and embedding it into the executable'..Other than that, I am out of ideas as to why you have '??'...
Not really. Sure you can dig around in memory and look at things. But without a stack trace you don't know how you got to where you are or what the parameter values were.
However, the very fact that your stack is corrupt tells you that you need to look for code that writes into the stack.
Overwriting a stack array. This can be done the obvious way or by calling a function or system call with bad size arguments or pointers of the wrong type.
Using a pointer or reference to a function's local stack variables after that function has returned.
Casting a pointer to a stack value to a pointer of the wrong size and using it.
If you have a Unix system, "valgrind" is a good tool for finding some of these problems.
I assume that since you say "My executable contains symbol table" that you compiled and linked with -g, and that your binary wasn't stripped.
We can just confirm this:
strings -a |grep function_name_you_know_should_exist
Also try using pstack on the core ans see if it does a better job of picking up the callstack. In that case it sounds like your gdb is out of date compared to your gcc/g++ version.
Sounds like you're not using the identical glibc version on your machine as the corefile was when it crashed on production. Get the files output by "ldd ./appname" and load them onto your machine, then tell gdb where to look;
set solib-absolute-prefix /path/to/libs