[Bug threads/10048] Apparent race in gdbserver causes it lose control of inferior

["pedro at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From pedro at codesourcery dot com  2009-04-08 21:16 -------
Subject: Re:  New: Apparent race in gdbserver causes it lose control of inferior

On Wednesday 08 April 2009 21:16:08, ppluzhnikov at google dot com wrote:
> ? main thread (LWP 23306) has been attached
> ? thread 0x40d77960 (LWP 23315) about to create new thread
> ? thread 0x41578960 (LWP 23316) about to crash
> 
> ? Child terminated with signal = 0xb (SIGSEGV)
> ? GDBserver exiting
> ? infrun: target_wait (-1, status) =
> ? infrun: ? 42000 [process 42000],
> ? infrun: ? status->kind = signalled, signal = SIGSEGV
> ? infrun: infwait_normal_state
> ? infrun: TARGET_WAITKIND_SIGNALLED

So, probably gdbserver didn't attach to the LWP that crashed.  Assuming
your kernel has support for PTRACE_EVENT_CLONE, gdbserver should have
seen a clone event, unless you are tripping on this FIXME ... :

 /* Attach to an inferior process.  */

 static void
 linux_attach_lwp_1 (unsigned long lwpid, int initial)
 {
...
   /* FIXME: This intermittently fails.
      We need to wait for SIGSTOP first.  */
   ptrace (PTRACE_SETOPTIONS, lwpid, 0, PTRACE_O_TRACECLONE);

If that is failing, gdbserver would not notice the new threads
being created, and the new threads wouldn't be traced, thus,
gdbserver would not be able to catch the SIGSEGV.

Does a patch-let like this:

 -  ptrace (PTRACE_SETOPTIONS, lwpid, 0, PTRACE_O_TRACECLONE);
 +  must_set_ptrace_flags = 1;

... make any difference?

stracing gdbserver would probably show what's going on.  Also running
gdbserver with 'gdbserver --debug' often helps spotting the issue.



-- 


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

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