Community
Participate
Working Groups
Created attachment 261252 [details] screenshot of the dynamic printf SIGTRAP issue This happens only in All-Stop mode, with multiple threads. It doesn't seem too sensitive to the gdb version (seems to happen with some or all of gdb 7.8 - 7.11 versions). It seems this issue is easier to reproduce with gdb 7.11, but is reproducible with older gdbs, down to 7.7. The idea is to make it so that multiple threads trigger dynamic printfs at the same time. It seems to help reproduce the issue if a normal breakpoint is added to the mix, triggering in between the DPFs. What seems to be happening is that, when a dynamic printf is hit, gdb calls the printf function of the inferior, to print. If the printf completes execution without being interrupted, everything is ok. However if it's interrupted by another thread also hitting a dynamic printf or normal breakpoint, then there is a problem. The following can be seen in the MI traces, when this happens: 011,104 &"warning: Unable to restore previously selected frame.\n" 011,104 &"The program received a signal in another thread while\n" 011,104 &"making a function call from GDB.\n" 011,104 &"Evaluation of the expression containing the function\n" 011,105 &"(malloc) will be abandoned.\n" 011,105 &"When the function is done executing, GDB will silently stop.\n" 011,108 56-stack-info-depth --thread 2 2 011,109 56^done,depth="2" 011,109 (gdb) When this happens, the Debug View behaves like the execution stopped at a dynamic printf (reason=User Request), which is strange. See attached screenshot that shows this state. The session is still up (but suspended) at that time, but if execution is resumed, then gdb becomes unresponsive and/or terminates: 075,525 ~"../../gdb/infrun.c:3104: internal-error: proceed: Assertion `!thread_is_in_step_over_chain\ (tp)' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable\ .\nQuit this debugging session? " 075,535 ~"(y or n) [answered Y; input not from terminal]\n" 075,535 &"\nThis is a bug, please report it." 075,535 &" For instructions, see:\n<http://www.gnu.org/software/gdb/bugs/>." 075,535 &"\n\n" 075,536 ~"../../gdb/infrun.c:3104: internal-error: proceed: Assertion `!thread_is_in_step_over_chain\ (tp)' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable\ .\nCreate a core file of GDB? " 075,536 ~"(y or n) [answered Y; input not from terminal]\n" Note: It seems that CDT configures dynamic printfs with the "call" option. Other options are available. When manually configuring the gdb session to use the "gdb" option instead, the problem doesn't seem to reproduce. i.e. "set dprintf-style gdb". I am not sure if there are downsides to using "gdb" instead of "call", generally. From the gdb manual: gdb: Handle the output using the gdb printf command. call: Handle the output by calling a function in your program (normally printf). [...] P.S. I have noticed something else a bit strange: when I am able to reproduce this using a single dynamic printf (i.e. no normal breakpoint, with gdb 7.11), it still reproduces even if the "Skip All Breakpoints" button is pushed. And un-intuively it still does stop on the d-printf line(s).
