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

Previous Next

Package: emacs;

Reported by: Katsumi Yamaoka <yamaoka <at> jpl.org>

Date: Fri, 7 Jun 2013 00:17:01 UTC

Severity: important

Found in version 24.3.50

Done: Ken Brown <kbrown <at> cornell.edu>

Bug is archived. No further changes may be made.

Full log


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

From: Angelo Graziosi <angelo.graziosi <at> alice.it>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: bug-emacs <bug-gnu-emacs <at> gnu.org>, Ken Brown <kbrown <at> cornell.edu>
Subject: Re: bug#14569: 24.3.50; bootstrap fails on Cygwin
Date: Mon, 01 Jul 2013 19:31:37 +0200
Il 01/07/2013 16.19, Paul Eggert ha scritto:
> 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 ();
>       }


It looks a nice solution. I have applied the patch and bootstrapped with

  CFLAGS=-DTICKLE_GLIB_BUGFIX ./my_build.sh

and it fails as expected. Instead the bootstrap

  ./my_build.sh

is completed just fine.

This way Cygwin gurus have a possibility to catch Mobydick, if it exists...


Ciao,
 Angelo.




This bug report was last modified 12 years and 1 day ago.

Previous Next


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