GNU bug report logs - #14569
24.3.50; bootstrap fails on Cygwin

Previous Next

Full log

View this message in rfc822 format

From: Ken Brown <kbrown <at> cornell.edu>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: "14569 <at> debbugs.gnu.org" <14569 <at> debbugs.gnu.org>, Angelo Graziosi <angelo.graziosi <at> alice.it>
Subject: bug#14569: 24.3.50; bootstrap fails on Cygwin
Date: Mon, 01 Jul 2013 12:16:25 -0400

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  <eggert <at> cs.ucla.edu>
> +
> +	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  <mina86 <at> mina86.com>
>
>   	* 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

Previous Next

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