aboutsummaryrefslogtreecommitdiff
path: root/gdb/ada-lang.h
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2015-02-19 20:48:54 +0000
committerPedro Alves <palves@redhat.com>2015-02-20 19:52:51 +0000
commitafa8d396f6a952d17b348a981dd2c56f83305611 (patch)
treeca177d0da6295d521a45083c04e573edf2fd5990 /gdb/ada-lang.h
parent60fb7e9efa12266437d28d19191e49e7f1e0013d (diff)
downloadgdb-afa8d396f6a952d17b348a981dd2c56f83305611.zip
gdb-afa8d396f6a952d17b348a981dd2c56f83305611.tar.gz
gdb-afa8d396f6a952d17b348a981dd2c56f83305611.tar.bz2
fix gdbserver/linux-low'c's pending status handling
Another fix I'm working made schedlock.exp fail with gdbserver frequently. Looking deeper, it turns out to be a pre-existing bug. status_pending_p_callback is filtering out LWPs incorrectly. The result is that that sometimes status_pending_p_callback returns a pending event for an LWP that isn't expected, and then GDBserver gets very confused. E.g,. when doing a step-over, linux_wait_for_event is called with a particular LWP's ptid, meaning events for all other LWPs should be left pending, but here we see it retuning an event for some other LWP: linux_wait_1: [<all threads>] step_over_bkpt set [LWP 29577.29577], doing a blocking wait <-------- my_waitpid (-1, 0x40000001) my_waitpid (-1, 0x80000001): status(57f), 0 LWFE: waitpid(-1, ...) returned 0, ERRNO-OK pc is 0x4007a0 src/gdb/gdbserver/linux-low.c:2587: A problem internal to GDBserver has been detected. linux_wait_1: got event for 29581 <-------- Remote connection closed (gdb) FAIL: gdb.threads/schedlock.exp: continue to breakpoint: return to loop (initial) delete breakpoints Tested on x86_64 Fedora 20. gdb/gdbserver/ChangeLog: 2015-02-20 Pedro Alves <palves@redhat.com> * linux-low.c (status_pending_p_callback): Use ptid_match.
Diffstat (limited to 'gdb/ada-lang.h')
0 files changed, 0 insertions, 0 deletions