aboutsummaryrefslogtreecommitdiff
path: root/gdb/tracefile-tfile.c
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2015-08-06 17:10:09 +0100
committerPedro Alves <palves@redhat.com>2015-08-06 17:10:09 +0100
commit608a1e46394e9df951968c9112fbec3065da5fba (patch)
treeb1fdb3a29064b24e840688c6a32ebcf6d691e8c4 /gdb/tracefile-tfile.c
parent05d999b0896ab6ccd4ce23a715765484c60a967d (diff)
downloadgdb-608a1e46394e9df951968c9112fbec3065da5fba.zip
gdb-608a1e46394e9df951968c9112fbec3065da5fba.tar.gz
gdb-608a1e46394e9df951968c9112fbec3065da5fba.tar.bz2
gdbserver: fix silent error exit
Running gdb.threads/process-dies-while-handling-bp.exp against gdbserver sometimes FAILs because GDBserver drops the connection, but the logs leave no clue on what the reason could be. Running manually a few times, I saw the same: $ ./gdbserver/gdbserver --multi :9999 testsuite/gdb.threads/process-dies-while-handling-bp Process testsuite/gdb.threads/process-dies-while-handling-bp created; pid = 12766 Listening on port 9999 Remote debugging from host 127.0.0.1 Listening on port 9999 Child exited with status 0 Child exited with status 0 What happened is that an exception escaped and gdbserver reopened the connection, which led to that second "Listening on port 9999" output. The error was a failure to access registers from a now-dead thread. The exception probably shouldn't have escaped here, but meanwhile, this at least makes the issue less mysterious. Tested on x86_64 Fedora 20. gdb/gdbserver/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * server.c (captured_main): On error, print the exception message to stderr, and if run_once is set, throw a quit.
Diffstat (limited to 'gdb/tracefile-tfile.c')
0 files changed, 0 insertions, 0 deletions