aboutsummaryrefslogtreecommitdiff
path: root/gdb/python/py-exitedevent.c
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2015-03-19 16:51:09 +0000
committerPedro Alves <palves@redhat.com>2015-03-19 16:51:09 +0000
commit91baf43fa70827325272667c8e7a86c553c767dc (patch)
treed86ff0e50c86c20bbde2a6c0d28f32da40fe6e09 /gdb/python/py-exitedevent.c
parent1740ba0cec44bdfe9cba586892a5953a4c602228 (diff)
downloadbinutils-91baf43fa70827325272667c8e7a86c553c767dc.zip
binutils-91baf43fa70827325272667c8e7a86c553c767dc.tar.gz
binutils-91baf43fa70827325272667c8e7a86c553c767dc.tar.bz2
gdbserver/Linux: unbreak non-stop
The previous change added an assertion that is catching yet another bug in count_events_callback/select_event_lwp_callback: (gdb) PASS: gdb.mi/mi-nonstop.exp: interrupted mi_expect_interrupt: expecting: \*stopped,(reason="signal-received",signal-name="0",signal-meaning="Signal 0"|reason="signal-received",signal-name="SIGINT",signal-meaning="Interrupt")[^ ]* /home/pedro/gdb/mygit/src/gdb/gdbserver/linux-low.c:2329: A problem internal to GDBserver has been detected. select_event_lwp: Assertion `num_events > 0' failed. =thread-group-exited,id="i1" Certainly select_event_lwp_callback should always at least find one event, as it's only called because an event triggered (though we may have more than one: the point of the function is randomly picking one). An LWP that GDB previously asked to continue/step (thus is resumed) and gets a vCont;t request ends up with last_resume_kind == resume_stop. These functions in gdbserver used to filter out events that weren't going to be reported to GDB; I think the last_resume_kind kind check used to make sense at that point, but it no longer does. gdb/gdbserver/ChangeLog: 2015-03-19 Pedro Alves <palves@redhat.com> * linux-low.c (count_events_callback, select_event_lwp_callback): No longer check whether the thread has resume_stop as last resume kind.
Diffstat (limited to 'gdb/python/py-exitedevent.c')
0 files changed, 0 insertions, 0 deletions