diff options
| author | Jan Kratochvil <jan.kratochvil@redhat.com> | 2014-09-12 13:39:04 +0200 |
|---|---|---|
| committer | Jan Kratochvil <jan.kratochvil@redhat.com> | 2014-09-12 13:39:04 +0200 |
| commit | 1cf2f1b045e9e647f6dfd28829ff4592c588dcb7 (patch) | |
| tree | 5ce6cd27d71ba5a21e13f7d7e9492ad64c238b34 /include/longlong.h | |
| parent | b006a80e5f41125c876a60a143ad421113533efc (diff) | |
| download | gdb-1cf2f1b045e9e647f6dfd28829ff4592c588dcb7.zip gdb-1cf2f1b045e9e647f6dfd28829ff4592c588dcb7.tar.gz gdb-1cf2f1b045e9e647f6dfd28829ff4592c588dcb7.tar.bz2 | |
testsuite: Fix runaway attach processes
I have started seeing occasional runaway 'attach' processes these days.
I cannot be certain it is really caused by this patch, for example
grep 'FAIL.*cmdline attach run' does not show anything in my logs.
But as I remember this 'attach' runaway process always happened in GDB (but
I do not remember it in the past months) I think it would be most safe to just
solve it forever by [attached].
gdb/testsuite/ChangeLog
2014-09-12 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.base/attach.c: Include unistd.h.
(main): Call alarm. Add label postloop.
* gdb.base/attach.exp (do_attach_tests): Use gdb_get_line_number,
gdb_breakpoint, gdb_continue_to_breakpoint.
(test_command_line_attach_run): Kill ${testpid} in one exit path.
Diffstat (limited to 'include/longlong.h')
0 files changed, 0 insertions, 0 deletions