bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#14569: 24.3.50; bootstrap fails on Cygwin


From: Ken Brown
Subject: bug#14569: 24.3.50; bootstrap fails on Cygwin
Date: Mon, 01 Jul 2013 12:16:25 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6

On 7/1/2013 10:19 AM, Paul Eggert wrote:
On 07/01/2013 04:21 AM, Ken Brown wrote:

Last night I began running a loop in which emacs (patched as I proposed) 
repeatedly starts and then
exits after 15 seconds [*].  So far there hasn't been a single failure after 
more than 1300 iterations.

I wouldn't expect your test case to exercise the bug.
The bug occurs when Gtk or Glib activity is occurring
in some other thread at the same time that Emacs is
running.  To reproduce the bug, one must have a
race condition like that.  In your test case Emacs
is idle, so it's unlikely to exhibit the bug.

A couple more things.  Since the bug comes into play
only when glib is tickled, shouldn't the Cygwin case
suppress only the tickling, not the catching of child
signals?

Also, wouldn't it be better to give Cygwin maintainers
an easy way to reproduce the bug, say by compiling
with a special flag?

So, how about the following patch instead?

=== modified file 'src/ChangeLog'
--- src/ChangeLog       2013-06-30 22:29:23 +0000
+++ src/ChangeLog       2013-07-01 14:17:45 +0000
@@ -1,3 +1,10 @@
+2013-07-01  Paul Eggert  <address@hidden>
+
+       Tickle glib when debugging under Cygwin (Bug#14569).
+       * process.c (init_process_emacs) [CYGWIN && TICKLE_GLIB_BUGFIX]:
+       Tickle glib in this case, too, so that Cygwin maintainers
+       can reproduce the bug more easily.
+
  2013-06-30  Michal Nazarewicz  <address@hidden>

        * buffer.c (FKill_buffer): Run `kill-buffer-query-functions'

=== modified file 'src/process.c'
--- src/process.c       2013-06-27 14:47:52 +0000
+++ src/process.c       2013-07-01 14:12:31 +0000
@@ -7095,16 +7095,24 @@
    if (! noninteractive || initialized)
  #endif
      {
-#if defined HAVE_GLIB && !defined WINDOWSNT && !defined CYGWIN
+#if defined HAVE_GLIB && !defined WINDOWSNT
        /* Tickle glib's child-handling code.  Ask glib to wait for Emacs 
itself;
         this should always fail, but is enough to initialize glib's
         private SIGCHLD handler, allowing the code below to copy it into
         LIB_CHILD_HANDLER.

-        For some reason tickling causes Cygwin bootstrap to fail, so it's
-        skipped under Cygwin.  FIXME: Skipping the tickling likely causes
-        bugs in subprocess handling under Cygwin (Bug#14569).  */
-      g_source_unref (g_child_watch_source_new (getpid ()));
+        Under Cygwin as of July 2013, tickling causes bootstrap to fail,
+        so do it only when Emacs is compiled with -DTICKLE_GLIB_BUGFIX;
+        this is to help Cygwin maintainers reproduce the bug.
+        FIXME: Skipping the tickling likely causes bugs in subprocess
+        handling under Cygwin (Bug#14569).  */
+# if defined CYGWIN && !defined TICKLE_GLIB_BUGFIX
+      bool tickle_glib = 0;
+# else
+      bool tickle_glib = 1;
+# endif
+      if (tickle_glib)
+       g_source_unref (g_child_watch_source_new (getpid ()));
  #endif
        catch_child_signal ();
      }

Yes, this looks good.  Please go ahead and apply it.

If it turns out that this really is a Cygwin/Glib bug (and not, say, a bug in gmalloc.c), it will be much easier to find the problem if I can provide the Cygwin maintainers with a test case in C, independent of Emacs. Is there a simple way to simulate the kind of race condition that you think is going on here?

Thanks.

Ken





reply via email to

[Prev in Thread] Current Thread [Next in Thread]