aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.base/gdb-sigterm.c
AgeCommit message (Collapse)AuthorFilesLines
2020-01-01Update copyright year range in all GDB files.Joel Brobecker1-1/+1
gdb/ChangeLog: Update copyright year range in all GDB files.
2019-01-01Update copyright year range in all GDB files.Joel Brobecker1-1/+1
This commit applies all changes made after running the gdb/copyright.py script. Note that one file was flagged by the script, due to an invalid copyright header (gdb/unittests/basic_string_view/element_access/char/empty.cc). As the file was copied from GCC's libstdc++-v3 testsuite, this commit leaves this file untouched for the time being; a patch to fix the header was sent to gcc-patches first. gdb/ChangeLog: Update copyright year range in all GDB files.
2018-01-02Update copyright year range in all GDB filesJoel Brobecker1-1/+1
gdb/ChangeLog: Update copyright year range in all GDB files
2017-01-01update copyright year range in GDB filesJoel Brobecker1-1/+1
This applies the second part of GDB's End of Year Procedure, which updates the copyright year range in all of GDB's files. gdb/ChangeLog: Update copyright year range in all GDB files.
2016-01-01GDB copyright headers update after running GDB's copyright.py script.Joel Brobecker1-1/+1
gdb/ChangeLog: Update year range in copyright notice of all files.
2015-02-06gdb.base/gdb-sigterm.exp: Fix spurious FAILsPedro Alves1-1/+5
The buildbot shows that some machines FAIL this test frequently. E.g.: https://sourceware.org/ml/gdb-testers/2015-q1/msg00997.html If I stress my machine, I can sometimes see it fail too. Bumping the 200 limit and tweaking the test to show the step count, I get: ... PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 12 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 8 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 13 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 7 times --> FAIL: gdb.base/gdb-sigterm.exp: SIGTERM stepped 228 times <-- PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 11 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 13 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 12 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 8 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 9 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 7 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 11 times PASS: gdb.base/gdb-sigterm.exp: SIGTERM stepped 8 times ... Thinking that this might be a problem of SIGTERM reaching GDB, but then the event loop taking too long to handle it, I hacked GDB to print a debug log whenever the SIGTERM handler was called, and, whenever the event loop finally calls the async SIGTERM handler. Here's what I see: infrun: 30011 [Thread 30011], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x4005de --> infrun: got SIGTERM <-- infrun: stepping inside range [0x4005de-0x4005e0] infrun: resume (step=1, signal=GDB_SIGNAL_0), ... infrun: prepare_to_wait --> infrun: handling async SIGTERM <-- Cannot execute this command while the target is running. Use the "interrupt" command to stop the target and then try again. gdb.base/gdb-sigterm.exp: expect eof #27 FAIL: gdb.base/gdb-sigterm.exp: SIGTERM stepped 228 times So, no delay on the GDB side. It just happens that occasionally it takes more than 200 single-steps before SIGTERM even reaches GDB. This just looks like a kernel/scheduling issue --- some extra usage spike in the system (e.g., an I/O spike) might cause it for me. For the build slaves, I'm guessing they're frequently busy enough to trip on this often. Particularly more so now that we're having them run tests in parallel mode. The fix is to detect failure by timeout instead of counting single steps. This should be more reliable. Indeed for me, after this commit, I couldn't trigger a FAIL anymore, even after letting the test run for an hour. By timeout is also nicer in that a board file for a slow host/target can increase it (like, e.g., an embedded GNU/Linux board). Tested on x86_64 Fedora 20, native, gdbserver, and extended-remote gdbserver. gdb/testsuite/ 2015-02-06 Pedro Alves <palves@redhat.com> * gdb.base/gdb-sigterm.c (main): Use the TIMEOUT define to determine how many seconds to pass to 'alarm'. * gdb.base/gdb-sigterm.exp (top level): Build program with -DTIMEOUT=$timeout. (do_test): Return success/failure indication. Add more verbose logging. Don't fail if 200 single steps are seen. Instead, fail when the test times out. (passes): New global. (top level): Break the testing loop if testing fails on any iteration. Use gdb_assert.
2015-01-01Update year range in copyright notice of all files owned by the GDB project.Joel Brobecker1-1/+1
gdb/ChangeLog: Update year range in copyright notice of all files.
2014-03-18Fix SIGTERM signal safety (PR gdb/15358).Jan Kratochvil1-0/+26
gdb/ 2014-03-18 Jan Kratochvil <jan.kratochvil@redhat.com> PR gdb/15358 * defs.h (sync_quit_force_run): New declaration. (QUIT): Check also SYNC_QUIT_FORCE_RUN. * event-top.c (async_sigterm_handler): New declaration. (async_sigterm_token): New variable. (async_init_signals): Create also async_sigterm_token. (async_sigterm_handler): New function. (sync_quit_force_run): New variable. (handle_sigterm): Replace quit_force call by other calls. * utils.c (quit): Call quit_force if SYNC_QUIT_FORCE_RUN. gdb/testsuite/ 2014-03-18 Jan Kratochvil <jan.kratochvil@redhat.com> PR gdb/15358 * gdb.base/gdb-sigterm.c: New file. * gdb.base/gdb-sigterm.exp: New file. Message-ID: <20140316135334.GA30698@host2.jankratochvil.net>
generated by cgit v1.1 at 2024-11-20 14:17:59 +0000