From: Pedro Alves Date: Mon, 30 Nov 2015 16:05:19 +0000 (+0000) Subject: gdbserver resume_stop handling bug X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=56cf4bed5354769d7352c5cf4e054a346d2553cd;p=binutils-gdb.git gdbserver resume_stop handling bug 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 * linux-low.c (resume_stopped_resumed_lwps): Don't check whether the thread's last_resume_kind was resume_stop. --- diff --git a/gdb/gdbserver/ChangeLog b/gdb/gdbserver/ChangeLog index 3d694aced7b..3d00ed431db 100644 --- a/gdb/gdbserver/ChangeLog +++ b/gdb/gdbserver/ChangeLog @@ -1,3 +1,8 @@ +2015-11-30 Pedro Alves + + * 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 * linux-low.c (linux_attach): In non-stop mode, wait for one stop diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c index 69fda7fe702..1f7d8d17f62 100644 --- a/gdb/gdbserver/linux-low.c +++ b/gdb/gdbserver/linux-low.c @@ -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;