diff options
author | Pedro Alves <palves@redhat.com> | 2015-08-06 17:10:09 +0100 |
---|---|---|
committer | Pedro Alves <palves@redhat.com> | 2015-08-06 17:10:09 +0100 |
commit | 608a1e46394e9df951968c9112fbec3065da5fba (patch) | |
tree | b1fdb3a29064b24e840688c6a32ebcf6d691e8c4 /gdb/exc_request.defs | |
parent | 05d999b0896ab6ccd4ce23a715765484c60a967d (diff) | |
download | gdb-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/exc_request.defs')
0 files changed, 0 insertions, 0 deletions