#1 0x0000000000407424 in main (argc=8, arguments=0x7fffffffcc38)Īt server/Metadata/XUDML/TestXUDMLParser/TestXUDMLParser.cpp:101 >catch catch - catch all exceptions - this will not tell you where the exception is thrown. (gdb) show verbose // set verbose on /// show logging //set log file filename.txt (gdb) info args - arguments of the current stack frame (gdb) info local - local variables of the current stack frame (gdb) info variables - show all global and static variables The statement at line 27 of the function mystrcpy is the next statement and the function mystrcpy was called by main.Įxecute the rest of the current function that is, step out of the function. Show the next statement that will be executed. When running the program via gdb, the output will also tell you the path to the libraries the program is depending on too.īreakpoint 1 at 0x80485b2: file cpptest.cpp, line 16.īreakpoint 2 at 0x80483f8: file test.c, line 19 >info break - list the current catchpoints This is the step just before an exception handler is called. >b _raise_exception - break at the code where the exception is thrown, notice sometimes catch catch won't give you this information >list linenum -print lines centered around linenumber >list -print lines just before the lines last printed >bt - backtrace, works ok in release build as well. >b programname_methodname -break at method name -args use this if program.exe has parameters I highlighted the ones related to catching exceptions. You can tell gdb to break at all exceptions being thrown and at the callers throwing the exceptions.īelow is an example showing the useful commands in gdb along with the case on how to find where the exception is being thrown. The next question is how do I know what exception to catch or what function to break? Normally this would cause a crash if the exception is not being handled, but since the program does not crash it means that the exception is being handled and a non zero exit code is returned. The first thing to think about is if there are any exceptions being thrown in the code. The program can be so huge and take a long time to run that it can be very frustrating if you have to run gdb more than once to reproduce or troubleshoot the issue. You may not know where to start or sometimes it is nearly impossible to go line by line to find the issue. Now you want to know what is causing the problem. The program may mysteriously exit or return none-zero exit code. Moving on to the case where the program does not segfault. I will talk in more details on how to troubleshoot using these programs in another article. >sudo pldd 1234 //will list all the library dependencies of a running process id 1234 >objdump -p programname | grep NEEDED //list all libraries dependencies >objdump programname //dump the whole binary >ldd programname //check and list all the dependencies files (*.so).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |