I want to debug my program (with multiple breakpoints) automatically. When reaching a breakpoint, I want to do some operations and continue the execution. Here is the code snippet of my python script: ``` def set_breakpoints(): # Just add multiple breakpoints ... def on_stop(event): # Do some operations gdb.post_event(lambda: gdb.execute("c")) gdb.events.stop.connect(on_stop) gdb.execute("run") ``` And here is my command: "gdb -x [MY_PYTHON_SCRIPT] --batch --args [MY_PROGRAM]". And then, gdb crashes with the following logs: ``` Fatal signal: Segmentation fault ----- Backtrace ----- 0x55a013532077 ??? 0x55a013634859 ??? 0x55a013634a22 ??? 0x7eff7742c51f ??? ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 0x7eff780093eb ??? 0x7eff78009f1b ??? 0x55a013797a2a ??? 0x55a0137d01d5 ??? 0x7eff7742f494 __run_exit_handlers ./stdlib/exit.c:113 0x7eff7742f60f __GI_exit ./stdlib/exit.c:143 0x55a01385f3e4 ??? 0x55a0136f3554 ??? 0x55a0136f404e ??? 0x55a01348a15f ??? 0x7eff77413d8f __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 0x7eff77413e3f __libc_start_main_impl ../csu/libc-start.c:392 0x55a01348fbf4 ??? 0xffffffffffffffff ??? --------------------- ``` Such crash only appears in batch mode. If I run the program in interactive mode, the program will not crash (but interactive mode is inefficient). Based on my test, this bug appears in version 12.1 and version 15.0.
That stack trace isn't really that useful. Could you try with git gdb? We fixed a bug like this recently.
(In reply to Tom Tromey from comment #1) > That stack trace isn't really that useful. > > Could you try with git gdb? > We fixed a bug like this recently. Very thanks for your timely response! I compile the gdb git project (head acab5b12b9765d856d8618c11e4f54115396fda7) and find the crash disappeared. However, it has a new bug --- the gdb will exit directly without continue executing. Recall that I aim to use 'gdb.post_event(lambda: gdb.execute("c"))' to continue the program after the stop event is finished, but it doesn't work. Recall that my demand is to continue executing the program after a breakpoint. So I further try to use 'gdb.execute("c")' without 'gdb.post_event()'. That is, the code is like this: ``` def on_stop(event): # Do some operations gdb.execute("c") gdb.events.stop.connect(on_stop) ``` Although this method can continue executing the program for a while, the python script will end with the error message "Python Exception <class 'RecursionError'>: maximum recursion depth exceeded while calling a Python object". I use python traceback and find that the python stack is filled with the 'on_stop()' function. It seems that a new 'on_stop()' function is executed even the last 'on_stop()' is still in stack. Such behavior leads stack overflow when gdb runs for a while.
In your case you probably want a breakpoint with a 'stop' method that returns False, instead. This area can probably be improved, though. I think what's happening is that the initial command completes, so gdb exits. Maybe resurrecting -i=python is a way to go. Unsure.