Use gdb to find where the program is stuck

My program does not work correctly. It appears to be stuck in an endless loop or bad lock / unlock mutex. But I do not know where the error is. I tried using gdb for debugging.

I cannot use the gdb backtrace command because I do not assign a breakpoint. And I cannot denote it, because I do not know where the error is.

Does gdb have a flyback tool?

+6
source share
3 answers

I cannot use the gdb backtrace command because I do not assign a breakpoint.

Yes, you can.

All you need is that somewhere the program is stopped somewhere (which is being debugged).

The first time you connect to the program, GDB will stop all streams, and you can check where they are. Later you can press Ctrl-C and see all the threads again. Useful command in thread apply all where .

+11
source

Get the process id from the "ps -ef" of your program. Use pstack to know exactly what function it hangs on. It prints a trace of the execution stack.

Output Example:

 $ pstack PROCESS_PID \#0 0x00000038cfaa664e in waitpid () from /lib64/libc.so.6 \#1 0x000000000043ed42 in ?? () \#2 0x000000000043ffbf in wait_for () \#3 0x0000000000430bc9 in execute_command_internal () \#4 0x0000000000430dbe in execute_command () \#5 0x000000000041d526 in reader_loop () \#6 0x000000000041ccde in main () 
+7
source

when you feel that you are inside some infinte loop during debugging, check the code and just

make a breakpoint after this possible loop and try to exit, you get an idea if

the breakpoint hit after this cycle, also after that you can analyze what is wrong in your

a variable either from this part of the code or to restart the sample reproduced in gdb.

-1
source

Source: https://habr.com/ru/post/972405/


All Articles