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]

[Bug threads/10757] GDB does not attach all threads of a multithreaded process => inferior gets SIGTRAP


------- Additional Comments From pedro at codesourcery dot com  2009-10-11 23:51 -------
Subject: Re:  GDB does not attach all threads of a multithreaded process => inferior gets SIGTRAP

On Monday 12 October 2009 00:27:46, ppluzhnikov at google dot com wrote:

> Please note that gdbserver is not involved in this bug report.
> SIGTRAP is happening with 'gdb --pid' or '(gdb) attach'.
> When using '(gdb) run' instead, everything works fine.

Ah, I got confused with the "This was originally reported
with gdbserver".  gdb/linux-thread-db.c seems to have the same
race anyway, but only if "set breakpoint always-inserted on",
as otherwise, breakpoint are only installed on the next
resume, after finding threads.

> In all cores I've examined, it was the breakpoint on foo().
> If I don't insert it, then I never get SIGTRAP.

This seems to confirm that GDB is inserting breakpoints
into the inferior's address space before having attached
to all threads.  Either that, or for some reason GDB is
managing to end up not attached to some but not all
threads when attaching to an inferior that is
spawning threads.  On an NTPL system, clone children of
ptraced lwps are already ptraced attached as well, although
I wouldn't discount a kernel bug (RedHat systems
being more suspectible to such bugs due to ptrace
on top of utrace reimplementation).  There could also
be an problem with new threads being added to glibc's
pthreads list just while thread_db is iterating
over them so that the iterator could miss new threads.
Dunno.

The basic premise is that GDB needs to attach to every
LWP running in the inferior, not just the main LWP.  If
an LWP hits a breakpoint before GDB having PTRACE_ATTACHed
to it, it will simply die with a SIGTRAP, because ptrace
won't intercept it.

Perhaps simply a breakpoint on "insert_breakpoints" can
confirm that gdb is inserting breakpoints too soon.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10757

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


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