3

I have been debugging in GDB (C code). The issue is if I run my application and if it crashes, the control comes back to main()(app restarts). Hence will have no idea where it crashed. So I spend a lot of time stepping through each function.

I would like to know if there is anyway a log can be enabled which will generate the last line of execution before crash. This is just my assumption, if there is any other simpler way of doing this please let me know, this would save a great deal of time for me!

Also if the gdb generates a log where would the path be?

Thanks in advance.

kp11
  • 2,055
  • 6
  • 22
  • 25
  • 2
    Can you define "crash"? If there's an unhandled signal (e.g. SIGSEGV) GDB should intercept it and stop there immediately, but it sounds like that's not what's happening, so you must be "crashing" in a different way – Michael Mrozek Dec 01 '10 at 04:26
  • 1
    GDB can handle canned commands if you can them. Or, if by log you mean a stack trace, look at http://tlug.up.ac.za/wiki/index.php/Obtaining_a_stack_trace_in_C_upon_SIGSEGV. It shows how to generate a stack trace on SIGSEGV. If you know which signal is causing your crash, generate the stack trace upon receiving that signal instead of SIGSEGV. – vpit3833 Dec 01 '10 at 04:31
  • Control returning to main() and application restarting aren't really the same thing - is it truly restarting at line 1 of main(), or is it just coming back to the line after some function call had an error and returned? – Cascabel Dec 01 '10 at 04:32
  • @vpit3833: Nice link :) – leppie Dec 01 '10 at 04:36
  • @Jefromi: No it does not come back to same function after executing. It starts all the initialization process again, which means the app has restarted. – kp11 Dec 01 '10 at 05:07
  • @ Michael Mrozek: You are correct, it throws the SIGSEGV by does not show where it happened. It throws that exception on gdb and restarts. – kp11 Dec 01 '10 at 05:09

2 Answers2

4

This question is a little unclear to me, but I'll take a stab:

If you have GDB attached to the crashing process when it crashes, a crash should stop the program and put you back at the (gdb) prompt. If you then type bt, you should see the stack.

If you do NOT have GDB attached, then this answer to a related question might help. (In short, maybe you want the system to create a core dump when the program crashes. A core dump is just a file that contains a lot of information about the crashed process. You can use GDB with the core dump to see the stack.)

If you don't know, post what you see on the screen when this happens, and we'll guess.

In any case, the program definitely should not start over at main(). It seems worthwhile to track down why this happens and precisely what's going on. Does control really jump to main in the same process, as opposed to another process somehow being automatically started?

Community
  • 1
  • 1
Jason Orendorff
  • 42,793
  • 6
  • 62
  • 96
3

Run your program in gdb mode.

 $ gdb ./myProgram


Set break point to expected location.

 $ break functionName


Or set break point to particular line number.

 $ break 15


Start the execution

 $ r


Step into or step out the execution by 's' or 'n'

 $ s


once the program crash, do 'bt' for backtrace.

 $ bt


you can go up and down in your trace by 'up' & 'down' command

 $ up


Can also take alternate way. Debug program with “core” as the core dump file.

 $ gdb executableFilename core
 $ bt
akD
  • 1,137
  • 1
  • 10
  • 15