From: Doug Evans <xdje42@gmail.com>
To: gdb-patches@sourceware.org
Subject: Re: [PATCH][PR guile/17247] Block SIGCHLD while initializing Guile
Date: Tue, 09 Sep 2014 05:54:00 -0000 [thread overview]
Message-ID: <m3wq9ds5ja.fsf@sspiff.org> (raw)
In-Reply-To: <m31trwv5o1.fsf@sspiff.org> (Doug Evans's message of "Sun, 31 Aug 2014 12:07:58 -0700")
Doug Evans <xdje42@gmail.com> writes:
> 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.
Hi.
I have checked in this slight variation to trunk,
and will commit it to the 7.8 branch tomorrow.
commit 92d8d229d9a310ebfcfc13bf4a75a286c1add1ac
Author: Doug Evans <xdje42@gmail.com>
Date: Mon Sep 8 22:45:34 2014 -0700
Fix for PR 17247: Block SIGCHLD while initializing Guile.
The problem here is that if a thread other than gdb's main thread
gets a SIGCHLD (it's an asynchronous signal so the kernel will
essentially pick a random thread) then gdb will hang if it is
in sigsuspend when the SIGCHLD is delivered. The other thread
will see the signal and the sigsuspend won't "wake up".
Guile and libgc should be blocking SIGCHLD in their threads,
but we need to work with Guile 2.0 and libgc 7.4.
The problem first shows up in libgc 7.4 because it is the first
release that enables multiple marker threads by default.
gdb/ChangeLog:
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/ChangeLog b/gdb/ChangeLog
index ad5ef6f..9d3f392 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,5 +1,22 @@
2014-09-08 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.
+
+2014-09-08 Doug Evans <xdje42@gmail.com>
+
* guile/scm-cmd.c (gdbscm_parse_command_name): Replace magic number
with named constant. Fix style of pointer comparison.
* python/py-cmd.c (gdbpy_parse_command_name): Ditto.
diff --git a/gdb/config.in b/gdb/config.in
index b853412..f1593bd 100644
--- a/gdb/config.in
+++ b/gdb/config.in
@@ -141,9 +141,6 @@
/* Define if <sys/procfs.h> has fpregset_t. */
#undef HAVE_FPREGSET_T
-/* Define to 1 if you have the <gc/gc.h> header file. */
-#undef HAVE_GC_GC_H
-
/* Define to 1 if you have the `getgid' function. */
#undef HAVE_GETGID
@@ -348,9 +345,6 @@
/* Define to 1 if you have the `scm_new_smob' function. */
#undef HAVE_SCM_NEW_SMOB
-/* Define to 1 if you have the `setenv' function. */
-#undef HAVE_SETENV
-
/* Define to 1 if you have the `setlocale' function. */
#undef HAVE_SETLOCALE
diff --git a/gdb/configure b/gdb/configure
index bf141f1..350ec0c 100755
--- a/gdb/configure
+++ b/gdb/configure
@@ -9276,32 +9276,6 @@ else
fi
-# PR 17185, see if we can get the libgc version to see if we need
-# to apply the workaround.
-for ac_header in gc/gc.h
-do :
- ac_fn_c_check_header_mongrel "$LINENO" "gc/gc.h" "ac_cv_header_gc_gc_h" "$ac_includes_default"
-if test "x$ac_cv_header_gc_gc_h" = x""yes; then :
- cat >>confdefs.h <<_ACEOF
-#define HAVE_GC_GC_H 1
-_ACEOF
-
-fi
-
-done
-
-for ac_func in setenv
-do :
- ac_fn_c_check_func "$LINENO" "setenv" "ac_cv_func_setenv"
-if test "x$ac_cv_func_setenv" = x""yes; then :
- cat >>confdefs.h <<_ACEOF
-#define HAVE_SETENV 1
-_ACEOF
-
-fi
-done
-
-
# --------------------- #
# Check for libmcheck. #
# --------------------- #
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..97da042 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,39 +831,46 @@ extern initialize_file_ftype _initialize_guile;
void
_initialize_guile (void)
{
- char *msg;
-
install_gdb_commands ();
#if HAVE_GUILE
- /* The Python support puts the C side in module "_gdb", leaving the Python
- 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);
+ {
+#ifdef HAVE_SIGPROCMASK
+ sigset_t sigchld_mask, prev_mask;
#endif
+
+ /* The Python support puts the C side in module "_gdb", leaving the Python
+ side to define module "gdb" which imports "_gdb". There is evidently no
+ similar convention in Guile so we skip this. */
+
+#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.
+ Really libgc and Guile should do this, but we need to work with
+ libgc 7.4.x. */
+ 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.
+ Plus we need to initialize the Guile support while in Guile mode
+ (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
- /* scm_with_guile is the most portable way to initialize Guile.
- Plus we need to initialize the Guile support while in Guile mode
- (e.g., called from within a call to scm_with_guile). */
- scm_with_guile (call_initialize_gdb_module, NULL);
-
- /* 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
- backtrace if there's an error during initialization.
- OTOH, if the error is that gdb/init.scm wasn't found because gdb is being
- run from the build tree, the backtrace is more noise than signal.
- Sigh. */
- gdbscm_set_backtrace (0);
+ /* 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
+ backtrace if there's an error during initialization.
+ OTOH, if the error is that gdb/init.scm wasn't found because gdb is
+ being run from the build tree, the backtrace is more noise than signal.
+ Sigh. */
+ gdbscm_set_backtrace (0);
+ }
#endif
}
next prev parent reply other threads:[~2014-09-09 5:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-31 19:08 Doug Evans
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 [this message]
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=m3wq9ds5ja.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