This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gdb/2420: gdb SEGV with detach-on-follow=off


>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:


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]