This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug threads/10757] GDB does not attach all threads of a multithreaded process => inferior gets SIGTRAP
- From: "pedro at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: 11 Oct 2009 23:51:02 -0000
- Subject: [Bug threads/10757] GDB does not attach all threads of a multithreaded process => inferior gets SIGTRAP
- References: <20091011171907.10757.ppluzhnikov@google.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- 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.