]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit - gdb/gdbserver/ChangeLog
Fix gdbserver crash exposed by gdb.threads/process-dies-while-handling-bp.exp
authorPedro Alves <palves@redhat.com>
Fri, 21 Aug 2015 18:52:36 +0000 (19:52 +0100)
committerPedro Alves <palves@redhat.com>
Fri, 21 Aug 2015 18:52:36 +0000 (19:52 +0100)
commit465a859e0a991d3bfe8a9ee65a29a223c42e2ce7
tree42e184a6e0ffd4af4caaf9912b822a6c36d23beb
parentf0db101d9897732d6556456e542d12ecf9e12e42
Fix gdbserver crash exposed by gdb.threads/process-dies-while-handling-bp.exp

Running that test in a loop, I found a gdbserver core dump with the
following back trace:

 Core was generated by `../gdbserver/gdbserver --once --multi :2346'.
 Program terminated with signal SIGSEGV, Segmentation fault.
 #0  0x0000000000406ab6 in inferior_regcache_data (inferior=0x0) at src/gdb/gdbserver/inferiors.c:236
 236       return inferior->regcache_data;
 (gdb) up
 #1  0x0000000000406d7f in get_thread_regcache (thread=0x0, fetch=1) at src/gdb/gdbserver/regcache.c:31
 31        regcache = (struct regcache *) inferior_regcache_data (thread);
 (gdb) bt
 #0  0x0000000000406ab6 in inferior_regcache_data (inferior=0x0) at src/gdb/gdbserver/inferiors.c:236
 #1  0x0000000000406d7f in get_thread_regcache (thread=0x0, fetch=1) at src/gdb/gdbserver/regcache.c:31
 #2  0x0000000000409271 in prepare_resume_reply (buf=0x20dd593 "", ptid=..., status=0x20edce0) at src/gdb/gdbserver/remote-utils.c:1147
 #3  0x000000000040ab0a in vstop_notif_reply (event=0x20edcc0, own_buf=0x20dd590 "T05") at src/gdb/gdbserver/server.c:183
 #4  0x0000000000426b38 in notif_write_event (notif=0x66e6c0 <notif_stop>, own_buf=0x20dd590 "T05") at src/gdb/gdbserver/notif.c:69
 #5  0x0000000000426c55 in handle_notif_ack (own_buf=0x20dd590 "T05", packet_len=8) at src/gdb/gdbserver/notif.c:113
 #6  0x000000000041118f in handle_v_requests (own_buf=0x20dd590 "T05", packet_len=8, new_packet_len=0x7fff742c77b8)
     at src/gdb/gdbserver/server.c:2862
 #7  0x0000000000413850 in process_serial_event () at src/gdb/gdbserver/server.c:4148
 #8  0x0000000000413945 in handle_serial_event (err=0, client_data=0x0) at src/gdb/gdbserver/server.c:4196
 #9  0x000000000041a1ef in handle_file_event (event_file_desc=5) at src/gdb/gdbserver/event-loop.c:429
 #10 0x00000000004199b6 in process_event () at src/gdb/gdbserver/event-loop.c:184
 #11 0x000000000041a735 in start_event_loop () at src/gdb/gdbserver/event-loop.c:547
 #12 0x00000000004123d2 in captured_main (argc=4, argv=0x7fff742c7ac8) at src/gdb/gdbserver/server.c:3562
 #13 0x000000000041252e in main (argc=4, argv=0x7fff742c7ac8) at src/gdb/gdbserver/server.c:3631

Clearly this means that a thread pushed a stop reply in the event
queue, and then before GDB confused the event, the whole process died,
along with its thread.  But the pending thread event was left
dangling.  When GDB fetched that event, gdbserver looked up the
corresponding thread, but found NULL; not expecting this, gdbserver
crashes when it tries to read this thread's registers.

gdb/gdbserver/
2015-08-21  Pedro Alves  <palves@redhat.com>

PR gdb/18749
* inferiors.c (remove_thread): Discard any pending stop reply for
this thread.
* server.c (remove_all_on_match_pid): Rename to ...
(remove_all_on_match_ptid): ... this.  Work with a filter ptid
instead of a pid.
(discard_queued_stop_replies): Change parameter to a ptid.  Now
extern.
(handle_v_kill, kill_inferior_callback)
(process_serial_event): Adjust.
(captured_main): Call initialize_notif before starting the
program, thus before threads are created.
* server.h (discard_queued_stop_replies): Declare.
gdb/gdbserver/ChangeLog
gdb/gdbserver/inferiors.c
gdb/gdbserver/server.c
gdb/gdbserver/server.h