From: Doug Evans <xdje42@gmail.com>
To: gdb-patches@sourceware.org
Subject: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile
Date: Sun, 31 Aug 2014 19:08:00 -0000 [thread overview]
Message-ID: <m31trwv5o1.fsf@sspiff.org> (raw)
Hi.
This patch fixes PR 17247.
Basically, current Guile (git) starts an internal thread
(the "finalizer" thread), and libgc as of 7.4 now starts several
marker threads by default (before 7.4.0 one needed to configure
libgc with --enable-parallel-mark).
When other threads are running, and they haven't blocked SIGCHLD,
then the kernel may send SIGCHLD to these threads, leaving gdb
hung in the sigsuspend calls in linux-nat.c.
P.S. I have a tentative patch for PR 17314, which also fixes 17247,
but for a bit of robustness I'm applying both.
2014-08-31 Doug Evans <xdje42@gmail.com>
PR 17247
* guile.c: #include <signal.h>.
(_initialize_guile): Block SIGCHLD while initializing Guile.
Replaces the following, which is reverted.
2014-07-26 Doug Evans <xdje42@gmail.com>
PR 17185
* configure.ac: Add check for header gc/gc.h.
Add check for function setenv.
* configure: Regenerate.
* config.in: Regenerate.
* guile/guile.c (_initialize_guile): Add workaround for libgc 7.4.0.
diff --git a/gdb/configure.ac b/gdb/configure.ac
index 26c8ecf..ab7b1c2 100644
--- a/gdb/configure.ac
+++ b/gdb/configure.ac
@@ -1233,11 +1233,6 @@ AC_SUBST(GUILE_CPPFLAGS)
AC_SUBST(GUILE_LIBS)
AM_CONDITIONAL(HAVE_GUILE, test "${have_libguile}" != no)
-# PR 17185, see if we can get the libgc version to see if we need
-# to apply the workaround.
-AC_CHECK_HEADERS(gc/gc.h)
-AC_CHECK_FUNCS([setenv])
-
# --------------------- #
# Check for libmcheck. #
# --------------------- #
diff --git a/gdb/guile/guile.c b/gdb/guile/guile.c
index 575bb6c..40208d2 100644
--- a/gdb/guile/guile.c
+++ b/gdb/guile/guile.c
@@ -34,10 +34,8 @@
#ifdef HAVE_GUILE
#include "guile.h"
#include "guile-internal.h"
-#ifdef HAVE_GC_GC_H
-#include <gc/gc.h> /* PR 17185 */
-#endif
#endif
+#include <signal.h>
/* The Guile version we're using.
We *could* use the macros in libguile/version.h but that would preclude
@@ -833,7 +831,9 @@ extern initialize_file_ftype _initialize_guile;
void
_initialize_guile (void)
{
- char *msg;
+#ifdef HAVE_SIGPROCMASK
+ sigset_t sigchld_mask, prev_mask;
+#endif
install_gdb_commands ();
@@ -842,16 +842,13 @@ _initialize_guile (void)
side to define module "gdb" which imports "_gdb". There is evidently no
similar convention in Guile so we skip this. */
- /* PR 17185 There are problems with using libgc 7.4.0.
- Copy over the workaround Guile uses (Guile is working around a different
- problem, but the workaround is the same). */
-#if (GC_VERSION_MAJOR == 7 && GC_VERSION_MINOR == 4 && GC_VERSION_MICRO == 0)
- /* The bug is only known to appear with pthreads. We assume any system
- using pthreads also uses setenv (and not putenv). That is why we don't
- have a similar call to putenv here. */
-#if defined (HAVE_SETENV)
- setenv ("GC_MARKERS", "1", 1);
-#endif
+#ifdef HAVE_SIGPROCMASK
+ /* Before we initialize Guile, block SIGCHLD.
+ This is done so that all threads created during Guile initialization
+ have SIGCHLD blocked. PR 17247. */
+ sigemptyset (&sigchld_mask);
+ sigaddset (&sigchld_mask, SIGCHLD);
+ sigprocmask (SIG_BLOCK, &sigchld_mask, &prev_mask);
#endif
/* scm_with_guile is the most portable way to initialize Guile.
@@ -859,6 +856,10 @@ _initialize_guile (void)
(e.g., called from within a call to scm_with_guile). */
scm_with_guile (call_initialize_gdb_module, NULL);
+#ifdef HAVE_SIGPROCMASK
+ sigprocmask (SIG_SETMASK, &prev_mask, NULL);
+#endif
+
/* Set Guile's backtrace to match the "set guile print-stack" default.
[N.B. The two settings are still separate.]
But only do this after we've initialized Guile, it's nice to see a
next reply other threads:[~2014-08-31 19:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-31 19:08 Doug Evans [this message]
2014-08-31 19:36 ` Eli Zaretskii
2014-08-31 20:20 ` Doug Evans
2014-09-01 2:37 ` Eli Zaretskii
2014-09-01 10:11 ` Ludovic Courtès
2014-09-01 14:39 ` Eli Zaretskii
2014-09-01 16:18 ` Ludovic Courtès
2014-09-01 17:10 ` Eli Zaretskii
2014-09-01 22:04 ` Doug Evans
2014-09-02 15:25 ` Eli Zaretskii
2014-09-05 8:27 ` Doug Evans
2014-09-05 8:48 ` Eli Zaretskii
2014-09-05 10:51 ` Pedro Alves
2014-09-05 11:51 ` Eli Zaretskii
2014-09-05 12:48 ` Pedro Alves
2014-09-05 11:50 ` Ludovic Courtès
2014-09-01 12:48 ` Gary Benson
2014-09-01 16:35 ` Doug Evans
2014-09-09 5:54 ` Doug Evans
2014-09-10 5:15 ` Doug Evans
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m31trwv5o1.fsf@sspiff.org \
--to=xdje42@gmail.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox