The buildbots show that attach-many-short-lived-thread.exp is racy.
But after staring at debug logs and playing with SystemTap scripts for
a (long) while, I figured out that neither GDB, nor the kernel nor the
test's program itself are at fault.
The problem is simply that the testsuite machinery is currently
subject to PID-reuse races. The attach-many-short-lived-threads.c
test program just happens to be much more susceptible to trigger this
race because threads and processes share the same number space on
Linux, and the test spawns many many short lived threads in
succession, thus enlarging the race window a lot.
Part of the problem is that several tests spawn processes with "exec&"
(in order to test the "attach" command) , and then at the end of the
test, to make sure things are cleaned up, issue a 'remote_spawn "kill
-p $testpid"'. Since with tcl's "exec&", tcl itself is responsible
for reaping the process's exit status, when we go kill the process,
testpid may have already exited _and_ its status may have (and often
has) been reaped already. Thus it can happen that another process
meanwhile reuses $testpid, and that "kill" command kills the wrong
process... Frequently, that happens to be
attach-many-short-lived-thread, but this explains other test's races
as well.
In the attach-many-short-lived-threads test, it sometimes manifests
like this:
(gdb) file /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/attach-many-short-lived-threads
Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/attach-many-short-lived-threads...done.
(gdb) Loaded /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/attach-many-short-lived-threads into /home/pedro/gdb/mygit/build/gdb/testsuite/../../gdb/gdb
attach 5940
Attaching to program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/attach-many-short-lived-threads, process 5940
warning: process 5940 is a zombie - the process has already terminated
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ptrace: Operation not permitted.
(gdb) PASS: gdb.threads/attach-many-short-lived-threads.exp: iter 1: attach
info threads
No threads.
(gdb) PASS: gdb.threads/attach-many-short-lived-threads.exp: iter 1: no new threads
set breakpoint always-inserted on
(gdb) PASS: gdb.threads/attach-many-short-lived-threads.exp: iter 1: set breakpoint always-inserted on
Other times the process dies while the test is ongoing (the process is
ptrace-stopped):
(gdb) print again = 1
Cannot access memory at address 0x6020cc
(gdb) FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 2: reset timer in the inferior
(Recall that on Linux, SIGKILL is not interceptable)
And other times it dies just while we're detaching:
$4 = 319
(gdb) PASS: gdb.threads/attach-many-short-lived-threads.exp: iter 2: print seconds_left
detach
Can't detach Thread 0x7fb13b7de700 (LWP 1842): No such process
(gdb) FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 2: detach
GDB mishandles the latter (it should ignore ESRCH while detaching just
like when continuing), but that's another story.
The fix here is to change spawn_wait_for_attach to use Expect's
'spawn' command instead of Tcl's 'exec&' to spawn programs, because
with spawn we control when to wait for/reap the process. That allows
killing the process by PID without being subject to pid-reuse races,
because even if the process is already dead, the kernel won't reuse
the process's PID until the zombie is reaped.
The other part of the problem lies in DejaGnu itself, unfortunately.
I have occasionally seen tests (attach-many-short-lived-threads
included, but not only that one) die with a random inexplicable
SIGTERM too, and that too is caused by the same reason, except that in
that case, the rogue SIGTERM is sent from this bit in DejaGnu's remote.exp:
exec sh -c "exec > /dev/null 2>&1 && (kill -2 $pgid || kill -2 $pid) && sleep 5 && (kill $pgid || kill $pid) && sleep 5 && (kill -9 $pgid || kill -9 $pid) &"
...
catch "wait -i $shell_id"
Even if the program exits promptly, that whole cascade of kills
carries on in the background, thus potentially killing the poor
process that manages to reuse $pid...
I sent a fix for that to the DejaGnu list:
http://lists.gnu.org/archive/html/dejagnu/2015-07/msg00000.html
With both patches in place, I haven't seen
attach-many-short-lived-threads.exp fail again.
Tested on x86_64 Fedora 20, native, gdbserver and extended-gdbserver.
gdb/testsuite/ChangeLog:
2015-07-31 Pedro Alves <palves@redhat.com>
* gdb.base/attach-pie-misread.exp: Rename $res to $test_spawn_id.
Use spawn_id_get_pid. Wait for spawn id after eof. Use
kill_wait_spawned_process instead of explicit "kill -9".
* gdb.base/attach-pie-noexec.exp: Adjust to spawn_wait_for_attach
returning a spawn id instead of a pid. Use spawn_id_get_pid and
kill_wait_spawned_process.
* gdb.base/attach-twice.exp: Likewise.
* gdb.base/attach.exp: Likewise.
(do_command_attach_tests): Use gdb_spawn_with_cmdline_opts and
gdb_test_multiple.
* gdb.base/solib-overlap.exp: Adjust to spawn_wait_for_attach
returning a spawn id instead of a pid. Use spawn_id_get_pid and
kill_wait_spawned_process.
* gdb.base/valgrind-infcall.exp: Likewise.
* gdb.multi/multi-attach.exp: Likewise.
* gdb.python/py-prompt.exp: Likewise.
* gdb.python/py-sync-interp.exp: Likewise.
* gdb.server/ext-attach.exp: Likewise.
* gdb.threads/attach-into-signal.exp (corefunc): Use
spawn_wait_for_attach, spawn_id_get_pid and
kill_wait_spawned_process.
* gdb.threads/attach-many-short-lived-threads.exp: Adjust to
spawn_wait_for_attach returning a spawn id instead of a pid. Use
spawn_id_get_pid and kill_wait_spawned_process.
* gdb.threads/attach-stopped.exp (corefunc): Use
spawn_wait_for_attach, spawn_id_get_pid and
kill_wait_spawned_process.
* gdb.base/break-interp.exp: Rename $res to $test_spawn_id.
Use spawn_id_get_pid. Wait for spawn id after eof. Use
kill_wait_spawned_process instead of explicit "kill -9".
* lib/gdb.exp (can_spawn_for_attach): Adjust comment.
(kill_wait_spawned_process, spawn_id_get_pid): New procedures.
(spawn_wait_for_attach): Use spawn instead of exec to spawn
processes. Don't map cygwin/windows pids here. Now returns a
spawn id list.
Running gdb.threads/fork-plus-threads.exp against gdbserver in
extended-remote mode, even though the test passes, we still see broken
behavior:
(gdb) PASS: gdb.threads/fork-plus-threads.exp: set detach-on-fork off
continue &
Continuing.
(gdb) PASS: gdb.threads/fork-plus-threads.exp: continue &
[New Thread 28092.28092]
[Thread 28092.28092] #2 stopped.
[New Thread 28094.28094]
[Inferior 2 (process 28092) exited normally]
[New Thread 28094.28105]
[New Thread 28094.28109]
...
[Thread 28174.28174] #18 stopped.
[New Thread 28185.28185]
[Inferior 10 (process 28174) exited normally]
[New Thread 28185.28196]
[Thread 28185.28185] #20 stopped.
Cannot remove breakpoints because program is no longer writable.
Further execution is probably impossible.
[Inferior 11 (process 28185) exited normally]
[Inferior 1 (process 28091) exited normally]
PASS: gdb.threads/fork-plus-threads.exp: reached breakpoint
info threads
No threads.
(gdb) PASS: gdb.threads/fork-plus-threads.exp: no threads left
info inferiors
Num Description Executable
* 1 <null> /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/fork-plus-threads
(gdb) PASS: gdb.threads/fork-plus-threads.exp: only inferior 1 left
All the "[Thread FOO] #NN stopped." above are bogus, as well as the
"Cannot remove breakpoints because program is no longer writable.",
which is a consequence.
The problem is that when we intercept a fork event, we should report
the event for the parent, only, and leave the child stopped, but not
report its stop event. GDB later decides whether to follow the parent
or the child. But because handle_extended_wait does not set the
child's last_status.kind to TARGET_WAITKIND_STOPPED, a
stop_all_threads/unstop_all_lwps sequence (e.g., from trying to access
memory) by mistake ends up queueing a SIGSTOP on the child, resuming
it, and then when that SIGSTOP is intercepted, because the LWP has
last_resume_kind set to resume_stop, gdbserver reports the stop to
GDB, as GDB_SIGNAL_0:
...
>>>> entering unstop_all_lwps
unstopping all lwps
proceed_one_lwp: lwp 1600
client wants LWP to remain 1600 stopped
proceed_one_lwp: lwp 1828
Client wants LWP 1828 to stop. Making sure it has a SIGSTOP pending
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sending sigstop to lwp 1828
pc is 0x3615ebc7cc
Resuming lwp 1828 (continue, signal 0, stop expected)
continue from pc 0x3615ebc7cc
unstop_all_lwps done
sigchld_handler
<<<< exiting unstop_all_lwps
handling possible target event
>>>> entering linux_wait_1
linux_wait_1: [<all threads>]
my_waitpid (-1, 0x40000001)
my_waitpid (-1, 0x1): status(137f), 1828
LWFE: waitpid(-1, ...) returned 1828, ERRNO-OK
LLW: waitpid 1828 received Stopped (signal) (stopped)
pc is 0x3615ebc7cc
Expected stop.
LLW: resume_stop SIGSTOP caught for LWP 1828.1828.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
linux_wait_1 ret = LWP 1828.1828, 1, 0
<<<< exiting linux_wait_1
Writing resume reply for LWP 1828.1828:1
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Tested on x86_64 Fedora 20, extended-remote.
gdb/gdbserver/ChangeLog:
2015-07-30 Pedro Alves <palves@redhat.com>
* linux-low.c (handle_extended_wait): Set the child's last
reported status to TARGET_WAITKIND_STOPPED.
The new gdb.threads/fork-plus-threads.exp test exposes one more
problem. When one types "info inferiors" after running the program,
one see's a couple inferior left still, while there should only be
inferior #1 left. E.g.:
(gdb) info inferiors
Num Description Executable
4 process 8393 /home/pedro/bugs/src/test
2 process 8388 /home/pedro/bugs/src/test
* 1 <null> /home/pedro/bugs/src/test
(gdb) info threads
Calling prune_inferiors() manually at this point (from a top gdb) does
not remove them, because they still have inf->pid != 0 (while they
shouldn't). This suggests that we never mourned those inferiors.
Enabling logs (master + previous patch) we see:
...
WL: waitpid Thread 0x7ffff7fc2740 (LWP 9513) received Trace/breakpoint trap (stopped)
WL: Handling extended status 0x03057f
LHEW: Got clone event from LWP 9513, new child is LWP 9579
[New Thread 0x7ffff37b8700 (LWP 9579)]
WL: waitpid Thread 0x7ffff7fc2740 (LWP 9508) received 0 (exited)
WL: Thread 0x7ffff7fc2740 (LWP 9508) exited.
^^^^^^^^
[Thread 0x7ffff7fc2740 (LWP 9508) exited]
WL: waitpid Thread 0x7ffff7fc2740 (LWP 9499) received 0 (exited)
WL: Thread 0x7ffff7fc2740 (LWP 9499) exited.
[Thread 0x7ffff7fc2740 (LWP 9499) exited]
RSRL: resuming stopped-resumed LWP Thread 0x7ffff37b8700 (LWP 9579) at 0x3615ef4ce1: step=0
...
(gdb) info inferiors
Num Description Executable
5 process 9508 /home/pedro/bugs/src/test
^^^^
4 process 9503 /home/pedro/bugs/src/test
3 process 9500 /home/pedro/bugs/src/test
2 process 9499 /home/pedro/bugs/src/test
* 1 <null> /home/pedro/bugs/src/test
(gdb)
...
Note the "Thread 0x7ffff7fc2740 (LWP 9508) exited." line.
That's this in wait_lwp:
/* Check if the thread has exited. */
if (WIFEXITED (status) || WIFSIGNALED (status))
{
thread_dead = 1;
if (debug_linux_nat)
fprintf_unfiltered (gdb_stdlog, "WL: %s exited.\n",
target_pid_to_str (lp->ptid));
}
}
That was the leader thread reporting an exit, meaning the whole
process is gone. So the problem is that this code doesn't understand
that an WIFEXITED status of the leader LWP should be reported to
infrun as process exit.
gdb/ChangeLog:
2015-07-30 Pedro Alves <palves@redhat.com>
PR threads/18600
* linux-nat.c (wait_lwp): Report to the core when thread group
leader exits.
gdb/testsuite/ChangeLog:
2015-07-30 Pedro Alves <palves@redhat.com>
PR threads/18600
* gdb.threads/fork-plus-threads.exp: Test that "info inferiors"
only shows inferior 1.
When a program forks and another process start threads while gdb is
handling the fork event, newly created threads are left stuck stopped
by gdb, even though gdb presents them as "running", to the user.
This can be seen with the test added by this patch. The test has the
inferior fork a certain number of times and waits for all children to
exit. Each fork child spawns a number of threads that do nothing and
joins them immediately. Normally, the program should run unimpeded
(from the point of view of the user) and exit very quickly. Without
this fix, it doesn't because of some threads left stopped by gdb, so
inferior 1 never exits.
The program triggers when a new clone thread is found while inside the
linux_stop_and_wait_all_lwps call in linux-thread-db.c:
linux_stop_and_wait_all_lwps ();
ALL_LWPS (lp)
if (ptid_get_pid (lp->ptid) == pid)
thread_from_lwp (lp->ptid);
linux_unstop_all_lwps ();
Within linux_stop_and_wait_all_lwps, we reach
linux_handle_extended_wait with the "stopping" parameter set to 1, and
because of that we don't mark the new lwp as resumed. As consequence,
the subsequent resume_stopped_resumed_lwps, called from
linux_unstop_all_lwps, never resumes the new LWP.
There's lots of cruft in linux_handle_extended_wait that no longer
makes sense. On systems with CLONE events support, we don't rely on
libthread_db for thread listing anymore, so the code that preserves
stop_requested and the handling of last_resume_kind is all dead.
So the fix is to remove all that, and simply always mark the new LWP
as resumed, so that resume_stopped_resumed_lwps re-resumes it.
gdb/ChangeLog:
2015-07-30 Pedro Alves <palves@redhat.com>
Simon Marchi <simon.marchi@ericsson.com>
PR threads/18600
* linux-nat.c (linux_handle_extended_wait): On CLONE event, always
mark the new thread as resumed. Remove STOPPING parameter.
(wait_lwp): Adjust call to linux_handle_extended_wait.
(linux_nat_filter_event): Adjust call to
linux_handle_extended_wait.
(resume_stopped_resumed_lwps): Add debug output.
gdb/testsuite/ChangeLog:
2015-07-30 Simon Marchi <simon.marchi@ericsson.com>
Pedro Alves <palves@redhat.com>
PR threads/18600
* gdb.threads/fork-plus-threads.c: New file.
* gdb.threads/fork-plus-threads.exp: New file.
Just a slight cleanup. Committed as obvious.
gdb/testsuite/ChangeLog:
* gdb.base/batch-preserve-term-settings.exp
(test_terminal_settings_preserved_after_cli_exit): Use
send_quit_command.
Tested on x86_64 Debian Stretch, native, gdbserver and
extended-gdbserver. Also tested that the various error paths, like if
$PPID is empty or if SIGTERM did not not kill GDB, function correctly.
gdb/testsuite/ChangeLog:
* gdb.base/batch-preserve-term-settings.exp (send_quit_command):
New proc.
(test_terminal_settings_preserved_after_sigterm): New test.
Now that we can expect inferior output with the gdbserver boards, this
is all it takes to have the test pass against extended-remote
gdbserver.
Don Breazeal originally wrong something like this:
https://sourceware.org/ml/gdb-patches/2015-03/msg00506.html
which was what originally inspired the introduction of
$inferior_spawn_id.
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
Don Breazeal <donb@codesourcery.com>
* gdb.base/multi-forks.exp (continue_to_exit_bp_loc): Expect
output from both inferior_spawn_id and gdb_spawn_id.
Hi,
While examining BuildBot's logs, I noticed:
<https://sourceware.org/ml/gdb-testers/2015-q3/msg03767.html>
gdb.threads/attach-into-signal.exp has two nested loops and don't use
unique messages. This commit fixes that. Pushed under the obvious
rule.
gdb/testsuite/ChangeLog:
2015-07-29 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.threads/attach-into-signal.exp (corefunc): Use
with_test_prefix on nested loops, uniquefying the test messages.
My last commit d60a92216e introduced a
regression caused by a typo. This fixes it. Checked in as obvious.
Thanks to Pedro for reporting.
gdb/testsuite/ChangeLog:
2015-07-29 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.python/py-objfile.exp: Fix typo that snuck in from my last
commit.
When exiting GDB -- whether it's via the "quit" command, via a SIGTERM,
or otherwise -- we should leave the terminal in the state we acquired
it. To that end, we have to undo any modifications that may have been
made by the TUI (ncurses) or by the CLI (readline).
Tested on x86_64 Debian Stretch.
gdb/ChangeLog:
* top.c: Include "tui/tui.h".
(undo_terminal_modifications_before_exit): New static function.
(quit_force): Use it.
gdb/testsuite/ChangeLog:
* gdb.base/batch-preserve-term-settings.exp
(test_terminal_settings_preserved_after_cli_exit): New test.
See ChangeLog for details. No functional change intended.
Tested on x86_64 Debian Stretch by verifying that the gdb.log output
remains unchanged for native, gdbserver and extended-gdbserver.
gdb/testsuite/ChangeLog:
* gdb.base/batch-preserve-term-settings.exp: Remove top-level
manipulation of saved_gdbflags.
(test_terminal_settings_preserved): Remove global declaration of
the unused variable pagination_prompt. Remove manipulation of
saved_gdbflags. Use a local variable EXTRA_GDBFLAGS instead of
GDBFLAGS.
As all tests that check gdb,noinferiorio have been adjusted to expect
inferior output with "-i $inferior_spawn_id", we can remove this now,
and thus enable those tests against gdbserver.
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
* boards/gdbserver-base.exp: Don't set gdb,noinferiorio.
The following patch will remove the gdb,noinferiorio setting from the
gdbserver boards, so this bit can be reverted.
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
* gdb.base/interrupt.exp: Revert back to checking gdb,noinferiorio
at the top.
This forces all tests that rely on stdio to be unbuffered, like
interrupt.exp was adjusted in 6f98576f.
To recap, in some scenarios, GDB or GDBserver can be spawned with
input _not_ connected to a tty, and then tests that rely on stdio fail
with timeouts, because the inferior's stdout and stderr streams end up
fully buffered. Calling gdb_unbuffer_output forces output to be
unbuffered.
See https://sourceware.org/ml/gdb-patches/2015-02/msg00809.html and
https://sourceware.org/ml/gdb-patches/2015-02/msg00819.html.
Tested on x86_64 Fedora 20, native, and against a remote gdbserver
board file that connects to the target with ssh, with and without -t
(create pty).
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
* gdb.base/call-ar-st.c: Include "../lib/unbuffer_output.c".
(main): Call gdb_unbuffer_output.
* gdb.base/call-rt-st.c: Include "../lib/unbuffer_output.c".
(main): Call gdb_unbuffer_output.
* gdb.base/call-strs.c: Include "../lib/unbuffer_output.c".
(main): Call gdb_unbuffer_output.
* gdb.base/call-strs.exp: Adjust to step over the
gdb_unbuffer_output call.
* gdb.base/catch-gdb-caused-signals.c: Include
"../lib/unbuffer_output.c".
(main): Call gdb_unbuffer_output.
* gdb.base/dprintf.c: Include "../lib/unbuffer_output.c".
(main): Call gdb_unbuffer_output.
* gdb.base/ending-run.c: Include "../lib/unbuffer_output.c".
(main): Call gdb_unbuffer_output.
* gdb.base/run.c: Include "../lib/unbuffer_output.c".
(main): Call gdb_unbuffer_output.
* gdb.base/shlib-call.exp: Adjust to step over the
gdb_unbuffer_output call.
* gdb.base/shmain.c: Include "../lib/unbuffer_output.c".
(main): Call gdb_unbuffer_output.
* gdb.base/sizeof.c: Include "../lib/unbuffer_output.c".
(main): Call gdb_unbuffer_output.
* gdb.base/varargs.c: Include "../lib/unbuffer_output.c".
(main): Rename to ...
(test): ... this.
(main): Reimplement.
* gdb.base/varargs.exp: Run to test instead of to main.
* gdb.mi/mi-dprintf.c: Include "../lib/unbuffer_output.c".
(main): Call gdb_unbuffer_output.
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
* gdb.mi/mi-dprintf.exp (mi_expect_dprintf): New procedure,
factore out from mi_continue_dprintf. For call-style dprintfs,
expect dprintf output out of $inferior_spawn_id.
(mi_continue_dprintf): Use mi_expect_dprintf.
* gdb.mi/mi-dprintf.c: Include "../lib/unbuffer_output.c".
(main): Call gdb_unbuffer_output.
Rather than trying to determine where (which spawn id) the inferior
output comes out from, which depends on e.g., remote that supports
file i/o remote protocol extension, vs remote that sends inferior
output through a separate $inferior_spawn_id, vs native debugging,
which sends output through $gdb_spawn_id, vs native debugging with a
test that uses "separate-inferior-tty" (like mi-console.exp does),
always expect inferior output from both $inferior_spawn_id and
$gdb_spawn_id.
mi-console.exp itself already copes with different possible outputs in
a similar way:
# Combine both outputs in a single pattern.
set output "($semihosted_output|$native_output)"
Fixes:
FAIL: gdb.mi/mi-console.exp: Testing console output inferior output (timeout)
when testing against local gdbserver with gdb,noinferiorio removed
from the board file.
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
* lib/mi-support.exp (mi_inferior_spawn_id): Delete.
(default_mi_gdb_start): Set inferior_spawn_id instead of
mi_inferior_spawn_id. If $inferior_spawn_id is not set, set it to
gdb_spawn_id.
(mi_gdb_test): Always expect inferior output from both
$inferior_spawn_id and $gdb_spawn_id.
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
* gdb.gdb/selftest.exp (test_with_self): Update comment. Use
send_inferior and $inferior_spawn_id.
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
* gdb.base/call-rt-st.exp (print_struct_call): Split "result"
parameter into two new parameters, "inf_result" and "gdb_result".
Expect inferior output and gdb output from $inferior_spawn_id and
$gdb_spawn_id, respectively. Adjust all callers.
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
* gdb.base/call-ar-st.exp: Use gdb_test_stdio+multi_line instead
of gdb_test_sequence.
This one is a little more complicated than the other patches in this
series, because of the exit status wrapper handling, requiring a
little state machine.
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
* gdb.base/a2-run.exp (saw_usage, saw_exit_wrapper)
(saw_spurious_output): Expect inferior output from
$inferior_spawn_id. Use gdb_test_stdio.
This one needed a larger revamp. The issue is that the "info
breakpoints" test at the bottom of the file is broken on targets that
can do both server-side dprintf, and inferior I/O, because then
neither the breakpoint numbers match nor the "already hit N times"
output.
Address that by making the test restart gdb from scratch when
switching between dprintf styles. Test groups are factored into
procedures, and we now use with_test_prefix. While we're changing
test messages, lowercase a few test messages, and then while at it,
modernize a couple things here and there.
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
* gdb.base/dprintf.exp: Use standard_testfile. Change
prepare_for_testing call.
(srcfile): Don't set.
(restart): New procedure.
(test_dprintf): New procecure, use to continue over dprintfs.
(test_call, test_agent): New procedures, tests moved here.
Restart gdb and recreate dprintfs. Adjust expected output.
This adds a new helper procedure to be used by tests that rely on
stdio.
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_test_stdio): New procedure.
There seems to be no point in relying on stdio here. Simply use
gdb_continue_to_end instead.
(not removing the printf calls, as the .c file is half generated.)
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
* gdb.base/restore.exp (restore_tests): Use gdb_continue_to_end.
These tests rely on inferior I/O, but that seems pointless and
unrelated here. Simply remove the printf calls, and don't expect
them.
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
* gdb.base/call-signal-resume.exp: Remove check for
gdb,noinferiorio. Don't expect "no signal". Use gdb_test.
* gdb.base/unwindonsignal.exp: Likewise.
* gdb.base/call-signals.c (gen_signal): Remove printf call.
* gdb.base/unwindonsignal.c (gen_signal): Likewise.
No point in relying on stdio in this test. Simply run to a breakpoint
instead.
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
* gdb.base/siginfo-addr.c (pass): New function.
(handler): Call it iff si_addr is correct.
* gdb.base/siginfo-addr.exp: Remove gdb_skip_stdio_test check.
Set a breakpoint at "pass" and continue to it.
While running some regression tests, I noticed that the two Python
tests mentioned in the $SUBJECT contain non-unique names. This is a
violation of our guidelines:
<https://sourceware.org/gdb/wiki/GDBTestcaseCookbook#Make_sure_test_messages_are_unique>
And also makes things harder for BuildBot. So I hacked both testcases
and made every test name unique. I guess this could be considered an
obvious patch, but I decided to post it before pushing because others
may have different opinions about the names.
OK to apply?
gdb/testsuite/ChangeLog:
2015-07-28 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.python/py-objfile.exp: Make some tests have unique names.
* gdb.python/py-pp-registration.exp: Likewise.
This test fails with --target_board=native-extended-gdbserver because
it misses the usual "disconnect":
(gdb) spawn ../gdbserver/gdbserver --once :2347 /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.server/server-exec-info
Process /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.server/server-exec-info created; pid = 4736
Listening on port 2347
target extended-remote localhost:2347
Already connected to a remote target. Disconnect? (y or n) ^CsQuit
(gdb) et sysroot remote:
Undefined command: "et". Try "help".
(gdb) n
The program is not being run.
(gdb) FAIL: gdb.server/server-exec-info.exp: set sysroot remote: (got interactive prompt)
info files
(gdb) FAIL: gdb.server/server-exec-info.exp: info files
gdb/testsuite/ChangeLog:
2015-07-28 Pedro Alves <palves@redhat.com>
* gdb.server/server-exec-info.exp: Issue a "disconnect".
Using gcc 5.2 (maybe other versions as well), building mi-pending.c gives
these warnings:
./gdb.mi/mi-pending.c: In function ‘thread_func’:
./gdb.mi/mi-pending.c:34:5: warning: ‘return’ with no value, in function returning non-void
return;
^
./gdb.mi/mi-pending.c:38:5: warning: ‘return’ with no value, in function returning non-void
return;
^
gdb_compile_pthreads assumes that the build was successful only if there
is no output. These warnings therefore make gdb_compile_pthreads think
that the build failed, and the test doesn't run.
The easy fix is to replace the "return" with "return NULL". I am
pushing this as obvious.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-pending.c (thread_func): Replace return with return
NULL.
I noticed there was an unexpected pass in mi-watch.exp when running on
x86_64. Doing a bit of archeology shows that the xfail was added by
4a543da. This particular test failed on the MIPS architecture, which
the original contributor was working with. Here is the thread:
https://www.sourceware.org/ml/gdb-patches/2007-09/msg00151.html
Looking at the latest buildbot results for MIPS, it seems that it's also
an unexpected pass on that architecture. Therefore, I see no reason to
leave the xfail in place.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-watch.exp (test_watchpoint_triggering): Remove xfail.
GDB currently does not promptly quit after receiving a SIGTERM while no
proper target is active. This is because in handle_sigterm we currently
look at target_can_async_p to determine whether to asynchronously quit
GDB using an async signal handler or to asynchronously quit using the
quit flag. However, target_can_async_p is always false under the dummy
target, so under this target we always use the quit flag and not the
async signal handler to signal that GDB should quit. So GDB won't quit
until a code path that checks the quit flag is executed.
To fix this issue, this patch makes the SIGTERM handler no longer
inspect target_can_async_p, and instead makes the handler
unconditionally set the quit flag _and_ mark the corresponding async
signal handler, so that if the target is async (or if it's the dummy
target) then we will likely quit through the async signal handler, and
if it's not async then we will likely quit through the quit flag. This
redundant approach is similar to how we handle SIGINT.
gdb/ChangeLog:
* event-top.c (handle_sigterm): Don't inspect
target_can_async_p. Always set the quit flag and always mark
the async signal handler.
gdb/testsuite/ChangeLog:
* gdb.base/gdb-sigterm-2.exp: New test.
I happen to see REMOTE_EXAMPLES isn't used anywhere, so this patch
removes it.
REMOTE_EXAMPLES was added in the following commit in 1991,
commit 86bbb439c8
Author: John Gilmore <gnu@cygnus>
Date: Fri May 3 19:57:13 1991 +0000
There should be a Makefile in the cvs main directory, configured
for "./config.gdb none", so that things like "make tags" and "make tar"
will work.
and it was used like:
TARFILES = ${TAGFILES_MAINDIR} ${OTHERS} ${REMOTE_EXAMPLES}
However TARFILES was removed by the change latter in 1994,
Tue Aug 16 15:24:03 1994 Jim Kingdon (kingdon@lioth.cygnus.com)
* symtab.c (decode_line_1): If funfirstline and we get a
non-LOC_BLOCK symbol (e.g. variable or type), then error().
* Makefile.in (TARFILES, NONSRC, SFILES_STAND, SFILES_KGDB):
Remove; unused.
Since then, REMOTE_EXAMPLES is not used any more.
gdb:
2015-07-27 Yao Qi <yao.qi@linaro.org>
* Makefile.in (REMOTE_EXAMPLES): Remove it.
This reverts commit b558ff043d.
This reverts commit 4a11f20659.
The initial import commit failed to retain local changes made to
readline's configure.in (and the commit message erroneously stated that
there were no local changes that needed to be reapplied). Also the
import caused a couple of build errors and a scattering of testsuite
regressions throughout many arches. It's probably better to start over
with this import, hopefully more carefully next time.
Regressions, e.g.,
http://gdb-build.sergiodj.net/builders/Fedora-x86_64-m32/builds/1501
gdb/testsuite/ChangeLog:
Revert:
* Makefile.in (check/%.exp): Pass directory for GDB_PARALLEL.
(workers/%.worker, build-perf): New rule.
(GDB_PERFTEST_MODE): New variable.
(check-perf): Use it.
(clean): Clean up gdb.perf parallel build subdirs.
* lib/build-piece.exp: New file.
* lib/cache.exp (gdb_do_cache): Include $GDB_PARALLEL in path name.
* lib/gdb.exp (standard_output_file): Include $GDB_PARALLEL in path
name.
(standard_temp_file): Ditto.
(GDB_PARALLEL handling): Make outputs,temp,cache directories as subdirs
of $GDB_PARALLEL.
This patch syncs our upstream copy of readline from version 6.2 to the
latest version, 7.0 alpha (released July 10 2015).
I essentially copied what was done the last time readline was synced,
when Jan updated to readline 6.2 in 2011:
http://sourceware.org/ml/gdb-patches/2011-05/msg00003.html
Procedure:
1. I extracted the readline-7.0-alpha tarball on top of readline/.
2. I deleted all the new files under doc/ that were deliberately omitted
before.
3. I regenerated readline/configure and readline/examples/rlfe/configure
using autoconf 2.64. No other configure files need regenerating.
4. I updated the function gdb_printable_part in completer.c with a
trivial change made to the readline function it is based off of,
printable_part in readline/complete.c. There is more work to be done in
completer.c to sync it with readline/complete.c, but it is non-trivial
and should probably be done separately anyway.
Local patches that had to be reapplied:
None. readline 7.0 alpha contains all of our local readline
patches.
New files in readline/:
colors.{c,h}
examples/{hist_erasedups,hist_purgecmd,rl-callbacktest,rlbasic}.c
parse-colors.{c,h}
readline.pc.in
configure.ac
Deleted files in readline/:
configure.in
Regressions:
After the sync there is one testsuite regression, the test
"signal SIGINT" in gdb.gdb/selftest.exp which now FAILs. Previously,
the readline 6.2 SIGINT handler would temporarily reinstall the
underlying application's SIGINT handler and immediately re-raise SIGINT
so that the orginal handler gets invoked. But now (since readline 6.3)
its SIGINT handler does not re-raise SIGINT or directly invoke the
original handler; it now sets a flag marking that SIGINT was raised, and
waits until readline explicitly has control to call the application's
SIGINT handler. Anyway, because SIGINT is no longer re-raised from
within readline's SIGINT handler, doing "signal SIGINT" with a stopped
inferior gdb process will no longer resume and then immediately stop the
process (since there is no 2nd SIGINT to immediately catch). Instead,
the inferior gdb process will now just print "Quit" and continue to run.
So with this commit, this particular test case is adjusted to reflect
this change in behavior (we now have to send a 2nd SIGINT manually to
stop it).
Aside from this one testsuite regression, I personally noticed no
regression in user-visible behavior. Though I only tested on x86_64
and on i686 Debian Stretch.
Getting this kind of change in at the start of the GDB 7.11 development
cycle will allow us to get a lot of passive testing from developers and
from bleeding-edge users.
readline/ChangeLog.gdb:
Import readline 7.0 alpha
* configure: Regenerate.
* examples/rlfe/configure: Regenerate.
gdb/ChangeLog:
* completer.c (gdb_printable_part): Sync with readline function
it is based off of.
gdb/testsuite/ChangeLog:
* gdb.gdb/selftest.exp (test_with_self): Update test to now
expect the GDB inferior to no longer immediately stop after
being resumed with "signal SIGINT".
I think I lost a patch along the way, because I remember needing
something like this, but the reverted patch isn't the right way to
do this. Removing ...
gdb/testsuite/ChangeLog:
* gdb.perf/lib/perftest/measure.py (MeasurementCpuTime::stop): Print
result.
(MeasurementWallTime::stop): Ditto.
(MeasurementVmSizeTime::stop): Ditto.
These testcases are mocks of real programs.
GDB doesn't care what the programs do, they just have to look
and/or behave like the real program.
These testcases exercise gdb when debugging really large programs.
E.g., gmonster-1 has 10,000 CUs, and gmonster-2 has 1000 shared libs
(which is actually a little small, 5000 would be more accurate).
gdb/testsuite/ChangeLog:
* gdb.perf/lib/perftest/utils.py: New file.
* gdb.perf/gm-hello.cc: New file.
* gdb.perf/gm-pervasive-typedef.cc: New file.
* gdb.perf/gm-pervasive-typedef.h: New file.
* gdb.perf/gm-std.cc: New file.
* gdb.perf/gm-std.h: New file.
* gdb.perf/gm-use-cerr.cc: New file.
* gdb.perf/gm-utils.h: New file.
* gdb.perf/gmonster-null-lookup.py: New file.
* gdb.perf/gmonster-pervasive-typedef.py: New file.
* gdb.perf/gmonster-print-cerr.py: New file.
* gdb.perf/gmonster-ptype-string.py: New file.
* gdb.perf/gmonster-runto-main.py: New file.
* gdb.perf/gmonster-select-file.py: New file.
* gdb.perf/gmonster1-null-lookup.exp: New file.
* gdb.perf/gmonster1-pervasive-typedef.exp: New file.
* gdb.perf/gmonster1-print-cerr.exp: New file.
* gdb.perf/gmonster1-ptype-string.exp: New file.
* gdb.perf/gmonster1-runto-main.exp: New file.
* gdb.perf/gmonster1-select-file.exp: New file.
* gdb.perf/gmonster1.cc: New file.
* gdb.perf/gmonster1.exp: New file.
* gdb.perf/gmonster2-null-lookup.exp: New file.
* gdb.perf/gmonster2-pervasive-typedef.exp: New file.
* gdb.perf/gmonster2-print-cerr.exp: New file.
* gdb.perf/gmonster2-ptype-string.exp: New file.
* gdb.perf/gmonster2-runto-main.exp: New file.
* gdb.perf/gmonster2-select-file.exp: New file.
* gdb.perf/gmonster2.cc: New file.
* gdb.perf/gmonster2.exp: New file.
gdb/testsuite/ChangeLog:
* gdb.perf/README: New file.
* lib/perftest.exp (tcl_string_list_to_python_list): New function.
* lib/gen-perf-test.exp: New file.
Pedro Alves
Sandra Loosemore
Patrick Palka
Sergio Durigan Junior
Simon Marchi
Yao Qi
Doug Evans
Doug Evans