GNU bug report logs - #43066
Hang when forking new process.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 43066 in the body.
You can then email your comments to 43066 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <othacehe <at> gnu.org>
To: bug-guile <at> gnu.org
Subject: Hang when forking new process.
Date: Thu, 27 Aug 2020 09:42:47 +0200

[Message part 1 (text/plain, inline)]

Hello,

When forking, the finalization pipe file descriptors are
inherited. If the child process spawns a finalization thread, it will
use a copy of its parent finalization pipe file descriptors.

Hence, if the parent tries to stop its finalization thread, by forking
another process for instance, it may stop the child finalization thread
and hang forever waiting for its own finalization thread to stop.

Here's a small reproducer attached. On my machine, the program hangs
around iteration 100. Note that this has previously been discussed
here[1].

The attached patch should fix this by closing the finalization pipe file
descriptor copies in the child right after forking and opening a new
pipe by calling scm_init_finalizer_thread.

Thanks,

Mathieu

[1]: https://issues.guix.gnu.org/41948

[t.scm (application/octet-stream, attachment)]

[0001-Close-finalization-pipe-after-forking.patch (text/x-diff, inline)]

From 004c0c78c9c21c48b38d76b5d7b356b40c8e5a4a Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe <othacehe <at> gnu.org>
Date: Thu, 27 Aug 2020 09:16:55 +0200
Subject: [PATCH] Close finalization pipe after forking.

When forking, the finalization pipe file descriptors are
inherited. If the child process spawns a finalization thread, it will
use a copy of its parent finalization pipe file descriptors.

Hence, if the parent tries to stop its finalization thread, by forking
another process for instance, it may stop the child finalization thread
and hang forever for its own finalization thread to stop.

Fix it by closing the finalization pipe file descriptor copies in the
child right after forking and opening a new pipe by calling
scm_init_finalizer_thread.

* libguile/finalizers.c (scm_i_finalizer_post_fork): New function.
* libguile/finalizers.c (scm_i_finalizer_post_fork): Declare it.
* libguile/posix.c (scm_fork): Call it in the child process, right after forking.
---
 libguile/finalizers.c | 13 +++++++++++++
 libguile/finalizers.h |  1 +
 libguile/posix.c      |  4 ++++
 3 files changed, 18 insertions(+)

diff --git a/libguile/finalizers.c b/libguile/finalizers.c
index 0ae165fd1..b1803b34b 100644
--- a/libguile/finalizers.c
+++ b/libguile/finalizers.c
@@ -305,6 +305,19 @@ scm_i_finalizer_pre_fork (void)
 #endif
 }
 
+void
+scm_i_finalizer_post_fork (void)
+{
+#if SCM_USE_PTHREAD_THREADS
+  if (automatic_finalization_p)
+    {
+      close (finalization_pipe[0]);
+      close (finalization_pipe[1]);
+      scm_init_finalizer_thread ();
+    }
+#endif
+}
+
 
 
 
diff --git a/libguile/finalizers.h b/libguile/finalizers.h
index 44bafb22e..866e4d1eb 100644
--- a/libguile/finalizers.h
+++ b/libguile/finalizers.h
@@ -36,6 +36,7 @@ SCM_INTERNAL void scm_i_add_resuscitator (void *obj, scm_t_finalizer_proc,
                                           void *data);
 
 SCM_INTERNAL void scm_i_finalizer_pre_fork (void);
+SCM_INTERNAL void scm_i_finalizer_post_fork  (void);
 
 /* CALLBACK will be called after each garbage collection.  It will be
    called from a finalizer, which may be from an async or from another
diff --git a/libguile/posix.c b/libguile/posix.c
index 47769003a..022bda6e3 100644
--- a/libguile/posix.c
+++ b/libguile/posix.c
@@ -1247,6 +1247,10 @@ SCM_DEFINE (scm_fork, "primitive-fork", 0, 0, 0,
   pid = fork ();
   if (pid == -1)
     SCM_SYSERROR;
+
+  if (!pid)
+    scm_i_finalizer_post_fork ();
+
   return scm_from_int (pid);
 }
 #undef FUNC_NAME
-- 
2.28.0

Message #10 received at 43066-done <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Mathieu Othacehe <othacehe <at> gnu.org>
Cc: 43066-done <at> debbugs.gnu.org
Subject: Re: bug#43066: Hang when forking new process.
Date: Tue, 11 May 2021 12:43:33 +0200

Hi Mathieu,

Mathieu Othacehe <othacehe <at> gnu.org> skribis:

>>From 004c0c78c9c21c48b38d76b5d7b356b40c8e5a4a Mon Sep 17 00:00:00 2001
> From: Mathieu Othacehe <othacehe <at> gnu.org>
> Date: Thu, 27 Aug 2020 09:16:55 +0200
> Subject: [PATCH] Close finalization pipe after forking.
>
> When forking, the finalization pipe file descriptors are
> inherited. If the child process spawns a finalization thread, it will
> use a copy of its parent finalization pipe file descriptors.
>
> Hence, if the parent tries to stop its finalization thread, by forking
> another process for instance, it may stop the child finalization thread
> and hang forever for its own finalization thread to stop.
>
> Fix it by closing the finalization pipe file descriptor copies in the
> child right after forking and opening a new pipe by calling
> scm_init_finalizer_thread.
>
> * libguile/finalizers.c (scm_i_finalizer_post_fork): New function.
> * libguile/finalizers.c (scm_i_finalizer_post_fork): Declare it.
> * libguile/posix.c (scm_fork): Call it in the child process, right after forking.

Apologies for overlooking this patch!

This was fixed differently in 5a281e35f4a5ae78fbcf10591d9358bec8f0bee0,
which is in 3.0.7.

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.