aboutsummaryrefslogtreecommitdiff
path: root/bfd
diff options
context:
space:
mode:
authorJoel Brobecker <brobecker@adacore.com>2015-12-20 09:39:40 -0500
committerJoel Brobecker <brobecker@adacore.com>2015-12-22 19:28:10 +0400
commit4abd5ed2221c826bcb843794286777452de5c50b (patch)
tree195715a6485ead6d3d24945e43ced1d7e95f469a /bfd
parent0e50fe5ca6ed2ce780cbbfa516aec20b023433ce (diff)
downloadgdb-4abd5ed2221c826bcb843794286777452de5c50b.zip
gdb-4abd5ed2221c826bcb843794286777452de5c50b.tar.gz
gdb-4abd5ed2221c826bcb843794286777452de5c50b.tar.bz2
[lynxos] gdbserver hangs when killing inferior from GDB
With any program under GDBserver control on LynxOS, killing the program from the debugger (using the "kill" command) causes GDBserver to properly kill the inferior but GDBserver then hangs. This change of behavior occured after the following change was applied: commit f0ea042932e6922c90df3fd0001497d287b97677 Date: Mon Nov 30 16:05:27 2015 +0000 Subject: gdbserver: don't exit until GDB disconnects One of the changes introduced by the commit above is that process_serial_event no longer calls exit after handling the vKill packet. Instead, what happens is that we wait until captured_main finds that we no longer have any inferior to debug, at which point it throws_quit. This (normal) exception is then expected to propagate all the way to the exception handle in function "main", which calls exit. However, before the exception gets propagated, the cleanups are first executed, and one of the cleanups in question is detach_or_kill_for_exit_cleanup, which was put in place by captured_main. detach_or_kill_for_exit_cleanup is basically a wrapper around detach_or_kill_for_exit, which iterates over all inferiors, and kills them all. In our case, we have only one inferior, which we have already killed during the handling for the "vKill" packet. Unfortunately, we did not properly clean our internal data for that inferior up, and so detach_or_kill_for_exit thinks that we still have one inferior, and therefore tries to kill it. This results in lynx_kill being called, doing the following: lynx_ptrace (PTRACE_KILL, ptid, 0, 0, 0); lynx_wait (ptid, &status, 0); the_target->mourn (process); The hang is caused by the call to lynx_wait, which waits for an event from a process which does not exist... This patch fixes the issue by enhancing lynx_mourn to clean the threads and process list up. gdb/gdbserver/ChangeLog: * lynx-low.c (lynx_delete_thread_callback): New function. (lynx_mourn): Properly delete our process and all of its threads. Remove call to clear_inferiors.
Diffstat (limited to 'bfd')
0 files changed, 0 insertions, 0 deletions