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

login
register
mail settings
Submitter Tom de Vries
Date June 12, 2018, 3:51 p.m.
Message ID <20180612155134.7fninj4us5lq4hfc@localhost.localdomain>
Download mbox | patch
Permalink /patch/27754/
State New
Headers show

Comments

Tom de Vries - June 12, 2018, 3:51 p.m.
Hi,

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/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.

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.

OK for trunk?

Thanks,
- Tom

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

2018-06-12  Tom de Vries  <tdevries@suse.de>

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

---
 gdb/testsuite/gdb.base/fork-running-state.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)
Pedro Alves - June 13, 2018, 12:10 p.m.
On 06/12/2018 04:51 PM, Tom de Vries wrote:

> ...
> 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).

Whoops.

> ...
> So, AFAIU, once the parent is killed, there's no alarm to terminate the child.

Indeed.

Your patch is definitely a good idea.  Please push.

However, I think that still leaves an unnecessary delay until
the detached child/parent terminate.  They used to exit themselves,
but that caused a race, so they no longer do, see here:

 https://sourceware.org/ml/gdb-patches/2018-03/msg00588.html

Sounds like the best would be to restore the self-killing,
but make it controlled by a variable that gdb sets, depending
on whether gdb is staying attached to the child/parent.

Thanks,
Pedro Alves

Patch

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