[Bug testsuite/23269] New: fork-running-state hangs make check

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23269

Bug ID: 23269
Summary: fork-running-state hangs make check
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: testsuite
Assignee: unassigned at sourceware dot org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---

[ At fd161d860f1df7140153eab4726705cc3e2727b0 "Fri Jun 8 20:17:34 2018 +0930"
"Define various symbols conditionally in shared librarie". ]

When I run make check:
...
$ cd build/gdb
$ make check 2>&1 | tee ../CHECKLOG.gdb
...
I see after ~30m the summary of the test run printed, but make still hangs.

This seems to be due to some sleeping processes:
...
$ ps fx | grep fork-run
6475 ? S 0:00
build/gdb/testsuite/outputs/gdb.base/fork-running-state/fork-running-state
6451 ? S 0:00
gdb/testsuite/outputs/gdb.base/fork-running-state/fork-running-state
6427 ? S 0:00
gdb/testsuite/outputs/gdb.base/fork-running-state/fork-running-state
...

Killing the sleeping processes like this:
...
kill -9 $(ps -A | grep fork-running-st | awk '{print $1}')
...
allows make to finish.

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23269

Tom de Vries <vries at gcc dot gnu.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |palves at sourceware dot org

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23269

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
When running just fork-running-state.exp, make doesn't hang but the sleeping
processes are still visible.

Using this patch, I get just one hanging process:
...
diff --git a/gdb/testsuite/gdb.base/fork-running-state.exp
b/gdb/testsuite/gdb.base/fork-running-state.exp
index 27ed8a43e9..4ee1e116be 100644
--- a/gdb/testsuite/gdb.base/fork-running-state.exp
+++ b/gdb/testsuite/gdb.base/fork-running-state.exp
@@ -149,15 +149,9 @@ proc do_test { detach_on_fork follow_fork non_stop
schedule_multiple } {
# set non-stop on|off
# set schedule-multiple on|off

-foreach_with_prefix detach-on-fork {"off" "on"} {
- foreach_with_prefix follow-fork {"parent" "child"} {
- with_test_prefix "non-stop" {
- do_test ${detach-on-fork} ${follow-fork} "on" "-"
- }
- with_test_prefix "all-stop" {
- foreach_with_prefix schedule-multiple {"on" "off"} {
- do_test ${detach-on-fork} ${follow-fork} "off"
${schedule-multiple}
- }
- }
- }
-}
+set detach-on-fork "on"
+set follow-fork "parent"
+set non-stop "on"
+set schedule-multiple "-"
+
+do_test ${detach-on-fork} ${follow-fork} ${non-stop} ${schedule-multiple}
...

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 11064
--> https://sourceware.org/bugzilla/attachment.cgi?id=11064&action=edit
gdb.log

So, filtering out the PASS statements (and moving an -ex cmd to the prompt), we
have this debug session:
...
(gdb) set non-stop on
(gdb) break main
Breakpoint 1 at 0x400665: file
/home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base/fork-running-state.c,
line 52.
(gdb) run
Starting program:
/home/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/fork-running-state/fork-running-state

Breakpoint 1, main () at
/home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base/fork-running-state.c:52
52 save_parent = getpid ();
(gdb) set detach-on-fork on
(gdb) set follow-fork parent
(gdb) continue &
Continuing.
[Detaching after fork from child process 18797]
(gdb) info threads
Id Target Id Frame
* 1 process 18793 "fork-running-st" (running)
(gdb) set print inferior-events off
(gdb) kill inferior 1
...

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23269

Tom de Vries <vries at gcc dot gnu.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Keywords| |testsuite

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
The hanging process is the child process that gdb detaches from.

There's an alarm set in main before the fork, but:
...
$ man alarm
...
NOTES
Alarms created by alarm() are preserved across execve(2) and are not
inherited by children created via fork(2).
...
So, AFAIU, once the parent is killed, there's no alarm to terminate the child.

By moving the setting of the alarm into the fork_main/fork_child functions, we
make sure that the alarm also triggers for the child:
...
diff --git a/gdb/testsuite/gdb.base/fork-running-state.c
b/gdb/testsuite/gdb.base/fork-running-state.c
index 8ea4739609..65ca942ea0 100644
--- a/gdb/testsuite/gdb.base/fork-running-state.c
+++ b/gdb/testsuite/gdb.base/fork-running-state.c
@@ -27,6 +27,9 @@ int save_parent;
static int
fork_child (void)
{
+ /* Don't run forever. */
+ alarm (180);
+
while (1)
pause ();

@@ -38,6 +41,9 @@ fork_child (void)
static int
fork_parent (void)
{
+ /* Don't run forever. */
+ alarm (180);
+
while (1)
pause ();

@@ -51,9 +57,6 @@ main (void)

save_parent = getpid ();

- /* Don't run forever. */
- alarm (180);
-
/* The parent and child should basically run forever without
tripping on any debug event. We want to check that GDB updates
the parent and child running states correctly right after the
...

This works for the minimal fork-running-state.exp,, and for the original
fork-running-state.exp,: after 180 seconds, there are no sleeping processes
anymore.

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23269

--- Comment #4 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <***@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a08ac84b963facb4c4a85c4d5df057d44e2a276d

commit a08ac84b963facb4c4a85c4d5df057d44e2a276d
Author: Tom de Vries <***@suse.de>
Date: Sun Jun 10 15:21:31 2018 +0200

[gdb/testsuite] Fix hang in fork-running-state.c

When I run make check:
...
$ cd build/gdb
$ make check 2>&1 | tee ../CHECKLOG.gdb
...
I see after ~30m the summary of the test run printed, but make still hangs.

This seems to be due to some sleeping processes:
...
$ ps fx | grep fork-run
6475 ? S 0:00 gdb.base/fork-running-state/fork-running-state
6451 ? S 0:00 gdb.base/fork-running-state/fork-running-state
6427 ? S 0:00 gdb.base/fork-running-state/fork-running-state
...

Killing the sleeping processes like this:
...
kill -9 $(ps -A | grep fork-running-st | awk '{print $1}')
...
allows make to finish.

If I isolate one debug session from fork-running-state.exp that causes one
of
these sleeping processes, we get:
...
(gdb) set non-stop on
(gdb) break main
Breakpoint 1 at 0x400665: file
src/gdb/testsuite/gdb.base/fork-running-state.c,
line 52.
(gdb) run
Starting program: build/gdb/testsuite/outputs/gdb.base/fork-running-state/
fork-running-state

Breakpoint 1, main () at src/gdb/testsuite/gdb.base/fork-running-state.c:52
52 save_parent = getpid ();
(gdb) set detach-on-fork on
(gdb) set follow-fork parent
(gdb) continue &
Continuing.
[Detaching after fork from child process 18797]
(gdb) info threads
Id Target Id Frame
* 1 process 18793 "fork-running-st" (running)
(gdb) set print inferior-events off
(gdb) kill inferior 1
...
So, AFAIU, the hanging process is the child process that gdb detaches from.

There's an alarm set in main before the fork, but alarms are not preserved
in
the fork child:
...
$ man alarm
...
NOTES
Alarms created by alarm() are preserved across execve(2) and are not
inherited by children created via fork(2).
...
So, AFAIU, once the parent is killed, there's no alarm to terminate the
child.

The patch fixes this by moving the setting of the alarm into the
fork_main/fork_child functions, making sure that an alarm will trigger for
the child.

Tested with make check on x86_64.

2018-06-13 Tom de Vries <***@suse.de>

PR testsuite/23269
* gdb.base/fork-running-state.c (main): Move setting of alarm ...
(fork_child): ... here, and ...
(fork_parent): ... here.

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23269

Tom de Vries <vries at gcc dot gnu.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
Patch fixing test-case committed, marking resolved-fixed.