gdbserver resume_stop handling bug
authorPedro Alves <palves@redhat.com>
Mon, 30 Nov 2015 16:05:19 +0000 (16:05 +0000)
committerPedro Alves <palves@redhat.com>
Mon, 30 Nov 2015 18:39:37 +0000 (18:39 +0000)
Running attach-many-short-lived-threads.exp with the extended-remote
board with "maint set target-non-stop on" times out -- the attach
never completes.  Enabling infrun debug logs, we see that GDB is stuck
stopping all threads:

 infrun: target_wait (-1.0.0, status) =
 infrun:   1639.22213.0 [Thread 1639.22213],
 infrun:   status->kind = stopped, signal = GDB_SIGNAL_0
 infrun:   Thread 1639.22260 not executing
 infrun:   Thread 1639.22256 not executing
 infrun:   Thread 1639.22258 not executing
 infrun:   Thread 1639.22257 not executing
 infrun:   Thread 1639.22259 not executing
 infrun:   Thread 1639.22255 not executing
 infrun:   Thread 1639.22253 executing, already stopping
 infrun:   Thread 1639.22251 executing, already stopping
 infrun:   Thread 1639.22252 executing, already stopping
 infrun:   Thread 1639.22250 executing, already stopping
 infrun:   Thread 1639.22254 executing, already stopping
 infrun:   Thread 1639.22247 executing, already stopping
 infrun:   Thread 1639.22213 not executing
 infrun:   Thread 1639.22207 not executing
 infrun:   Thread 1639.22201 not executing
 infrun:   Thread 1639.22219 not executing
 infrun:   Thread 1639.1639 not executing
 ** HANG HERE **

GDB is waiting for the stop replies of any of those "already stopping"
threads.  Take 22253 for example.  On the gdbserver logs we see:

 ...
 resume_stop request for LWP 22253
 stopping LWP 22253
 Sending sigstop to lwp 22253
 linux_resume done
 ...

and:

 my_waitpid (-1, 0x40000001)
 my_waitpid (-1, 0x80000001): status(3057f), 22253
 LWFE: waitpid(-1, ...) returned 22253, ERRNO-OK
 LLW: waitpid 22253 received Trace/breakpoint trap (stopped)
 pc is 0x3615ef4ce1
 HEW: Got clone event from LWP 22253, new child is LWP 22259

but from here on, we never see any other event for LWP 22253.  In
particular, we never see the expected SIGSTOP (from "Sending sigstop"
above).  The issue is that linux_resume_stopped_resumed_lwps never
re-resumes the 22253 after the clone event.

gdb/gdbserver/ChangeLog:
2015-11-30  Pedro Alves  <palves@redhat.com>

* linux-low.c (resume_stopped_resumed_lwps): Don't check whether
the thread's last_resume_kind was resume_stop.

gdb/gdbserver/ChangeLog
gdb/gdbserver/linux-low.c

index 3d694aced7b25e7d50f739e60d73287e16594db6..3d00ed431db4665ab32cc04e1f5e3e1cb9be32b6 100644 (file)
@@ -1,3 +1,8 @@
+2015-11-30  Pedro Alves  <palves@redhat.com>
+
+       * linux-low.c (resume_stopped_resumed_lwps): Don't check whether
+       the thread's last_resume_kind was resume_stop.
+
 2015-11-30  Pedro Alves  <palves@redhat.com>
 
        * linux-low.c (linux_attach): In non-stop mode, wait for one stop
index 69fda7fe7021256cac2ed6dbf2df3e792894a149..1f7d8d17f6220cca9bb16f3da6e466510ed6f728 100644 (file)
@@ -2409,7 +2409,6 @@ resume_stopped_resumed_lwps (struct inferior_list_entry *entry)
   if (lp->stopped
       && !lp->suspended
       && !lp->status_pending_p
-      && thread->last_resume_kind != resume_stop
       && thread->last_status.kind == TARGET_WAITKIND_IGNORE)
     {
       int step = thread->last_resume_kind == resume_step;