This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
gdb/2420: gdb SEGV with detach-on-follow=off
- From: tromey at redhat dot com
- To: gdb-gnats at sources dot redhat dot com
- Date: 2 Mar 2008 17:06:27 -0000
- Subject: gdb/2420: gdb SEGV with detach-on-follow=off
- Reply-to: tromey at redhat dot com
>Number: 2420
>Category: gdb
>Synopsis: gdb SEGV with detach-on-follow=off
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Sun Mar 02 17:08:01 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator: Tom Tromey <tromey@redhat.com>
>Release: unknown-1.0
>Organization:
>Environment:
x86 FC-6
>Description:
I was pleased to find out about detach-on-fork = off.
I tried running gdb on gcc, to see I could end up debugging cc1:
/home/tromey/gnu/baseline-gdb/install/bin/gdb --args /home/tromey/gnu/incremental/install/bin/gcc /home/tromey/gnu/incremental/trunk/gcc/testsuite/gcc.dg/cpp/19930510-1.c -ansi -pedantic-errors -fno-show-column -S -o 19930510-1.s
Then I:
(gdb) set detach-on-fork off
(gdb) set follow-fork-mode child
(gdb) r
After cc1 starts, gdb crashes. Here is a partial stack trace:
Program received signal SIGSEGV, Segmentation fault.
0x080a18c5 in clear_lwpid_callback (thread=0x83e6790, dummy=0x0)
at ../../src/gdb/linux-thread-db.c:762
762 thread->private->th_valid = 0;
(gdb) bt
#0 0x080a18c5 in clear_lwpid_callback (thread=0x83e6790, dummy=0x0)
at ../../src/gdb/linux-thread-db.c:762
#1 0x08139883 in iterate_over_threads (
callback=0x80a18bc <clear_lwpid_callback>, data=0x0)
at ../../src/gdb/thread.c:212
#2 0x080a19a5 in thread_db_resume (ptid={pid = 29488, lwp = 29488, tid = 0},
step=1, signo=TARGET_SIGNAL_0) at ../../src/gdb/linux-thread-db.c:779
#3 0x0812d559 in resume (step=1, sig=TARGET_SIGNAL_0)
at ../../src/gdb/infrun.c:651
#4 0x08130cfc in keep_going (ecs=0xbfffe0cc) at ../../src/gdb/infrun.c:2970
#5 0x0812fd2d in handle_inferior_event (ecs=0xbfffe0cc)
clear_lwpid_callback unconditionally references thread->private, which is NULL.
Adding a check to avoid this fixes the crash for me.
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: