Using gdb 7.7 on Ubuntu 13.10 64 bit. gdb test -i mi (gdb) -gdb-set dprintf-style call ^done (gdb) -dprintf-insert test.cpp:13 "hello" ^done,bkpt={number="1",type="dprintf",disp="keep",enabled="y",addr="0x0000000000400861",func="main()",file="../src/test.cpp",fullname="/home/mark/Documents/dev/eclipse-4.4/workspace/test/src/test.cpp",line="13",thread-groups=["i1"],times="0",script={"call (void) printf (\"hello\")"},original-location="test.cpp:13"} (gdb) r &"r\n" ~"Starting program: /home/mark/Documents/dev/eclipse-4.4/workspace/test/Debug/test \n" =thread-group-started,id="i1",pid="8685" =thread-created,id="1",group-id="i1" ^running ... =library-loaded,id="/lib/x86_64-linux-gnu/libgcc_s.so.1",target-name="/lib/x86_64-linux-gnu/libgcc_s.so.1",host-name="/lib/x86_64-linux-gnu/libgcc_s.so.1",symbols-loaded="0",thread-group="i1" =breakpoint-modified,bkpt={number="1",type="dprintf",disp="keep",enabled="y",addr="0x0000000000400861",func="main()",file="../src/test.cpp",fullname="/home/mark/Documents/dev/eclipse-4.4/workspace/test/src/test.cpp",line="13",thread-groups=["i1"],times="0",script={"call (void) printf (\\"hello\\")"},original-location="test.cpp:13"} =breakpoint-modified,bkpt={number="1",type="dprintf",disp="keep",enabled="y",addr="0x0000000000400861",func="main()",file="../src/test.cpp",fullname="/home/mark/Documents/dev/eclipse-4.4/workspace/test/src/test.cpp",line="13",thread-groups=["i1"],times="1",script={"call (void) printf (\\"hello\\")"},original-location="test.cpp:13"} ~"\nProgram terminated with signal " ~"SIGSEGV, Segmentation fault.\n" ~"The program no longer exists.\n" =thread-exited,id="1",group-id="i1" =thread-group-exited,id="i1" *stopped Aborted (core dumped) The core dump doesn't seem very helpful: Core was generated by `/home/mark/Documents/dev/eclipse-4.4/workspace/test/Debug/test'. Program terminated with signal 11, Segmentation fault. #0 0x00007fffffffddff in ?? () (gdb) bt #0 0x00007fffffffddff in ?? () #1 0x0000000000601060 in data_start () #2 0xcc007ffff774a358 in ?? () #3 0x0000000000000001 in ?? () #4 0x00007fffffffde30 in ?? () #5 0x0000000000600df8 in ?? () #6 0x00000000004008bf in __static_initialization_and_destruction_0 (__initialize_p=32767, __priority=-8728) at /usr/include/c++/4.8/iostream:74 Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Created attachment 7537 [details] test source file
I'm sorry, I have to rectify the steps to reproduce the bug. I had a .gdbinit file in my home directory that affected the behavior. Here are the correct steps: (gdb) handle SIGSEGV nostop noprint &"handle SIGSEGV nostop noprint\n" ~"Signal Stop\tPrint\tPass to program\tDescription\n" ~"SIGSEGV No\tNo\tYes\t\tSegmentation fault\n" ^done (gdb) -gdb-set dprintf-style call ^done (gdb) -dprintf-insert test.cpp:13 "hello" ^done,bkpt={number="1",type="dprintf",disp="keep",enabled="y",addr="0x0000000000400861",func="main()",file="test.cpp",fullname="/home/emalape/git/gdb-7.7/install/bin/test.cpp",line="13",thread-groups=["i1"],times="0",script={"call (void) printf (\"hello\")"},original-location="test.cpp:13"} (gdb) r &"r\n" ~"Starting program: /home/emalape/git/gdb-7.7/install/bin/test \n" =thread-group-started,id="i1",pid="28110" =thread-created,id="1",group-id="i1" ^running ... =library-loaded,id="/lib/x86_64-linux-gnu/libgcc_s.so.1",target-name="/lib/x86_64-linux-gnu/libgcc_s.so.1",host-name="/lib/x86_64-linux-gnu/libgcc_s.so.1",symbols-loaded="0",thread-group="i1" =breakpoint-modified,bkpt={number="1",type="dprintf",disp="keep",enabled="y",addr="0x0000000000400861",func="main()",file="test.cpp",fullname="/home/emalape/git/gdb-7.7/install/bin/test.cpp",line="13",thread-groups=["i1"],times="0",script={"call (void) printf (\\"hello\\")"},original-location="test.cpp:13"} =breakpoint-modified,bkpt={number="1",type="dprintf",disp="keep",enabled="y",addr="0x0000000000400861",func="main()",file="test.cpp",fullname="/home/emalape/git/gdb-7.7/install/bin/test.cpp",line="13",thread-groups=["i1"],times="1",script={"call (void) printf (\\"hello\\")"},original-location="test.cpp:13"} ~"\nProgram terminated with signal " ~"SIGSEGV, Segmentation fault.\n" ~"The program no longer exists.\n" =thread-exited,id="1",group-id="i1" =thread-group-exited,id="i1" *stopped Aborted If only nostop is used then it works correctly: handle SIGSEGV nostop
The master branch has been updated by Antoine Tremblay <hexa@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c9587f88230e9df836f17c195181aaf50c3a1117 commit c9587f88230e9df836f17c195181aaf50c3a1117 Author: Antoine Tremblay <antoine.tremblay@ericsson.com> Date: Thu Feb 12 14:55:08 2015 -0500 Fix non executable stack handling when calling functions in the inferior. When gdb creates a dummy frame to execute a function in the inferior, the process may generate a SIGSEGV, SIGTRAP or SIGILL because the stack is non executable. If the signal handler set in gdb has option print or stop enabled for these signals gdb handles this correctly. However, in the case of noprint and nostop the signal is short-circuited and the inferior process is sent the signal directly. This causes the inferior to crash because of gdb. This patch adds a check for SIGSEGV, SIGTRAP or SIGILL so that these signals are sent to gdb rather than short-circuited in the inferior. gdb then handles them properly and the inferior process does not crash. This patch also fixes the same behavior in gdbserver. Also added a small testcase to test the issue called catch-gdb-caused-signals. This applies to Linux only, tested on Linux. gdb/ChangeLog: PR breakpoints/16812 * linux-nat.c (linux_nat_filter_event): Report SIGTRAP,SIGILL,SIGSEGV. * nat/linux-ptrace.c (linux_wstatus_maybe_breakpoint): Add. * nat/linux-ptrace.h: Add linux_wstatus_maybe_breakpoint. gdb/gdbserver/ChangeLog: PR breakpoints/16812 * linux-low.c (wstatus_maybe_breakpoint): Remove. (linux_low_filter_event): Update wstatus_maybe_breakpoint name. (linux_wait_1): Report SIGTRAP,SIGILL,SIGSEGV. gdb/testsuite/ChangeLog: PR breakpoints/16812 * gdb.base/catch-gdb-caused-signals.c: New file. * gdb.base/catch-gdb-caused-signals.exp: New file.
Fixed by c9587f88230e9df836f17c195181aaf50c3a1117
*** Bug 17970 has been marked as a duplicate of this bug. ***