RE: ICE for AutoGen-5.1.3

[Bruce Korb <bkorb at allegronetworks dot com>]

Alexandre Duret-Lutz wrote:
> Here goes the story.  Some parts of it are still fuzzy for me 
> and I'd love to understand them fully, so don't hesitate to
> comment on and correct me.

Right on.  Thank you.  You have resolved an issue that has
plagued me since egcs moved to the 2.95 series.

> As written in a previous mail, the trouble happens when
> waiting for a child to exit, and this child is `cpp0' (the
> preprocessor).  Running strace on the ICE'ing gcc incantation gives
> the following outputs.
> 
> When run from autogen, you see something like this:
> 
> [...]
> open("/tmp/ccZAkg5b.i", O_RDWR|O_CREAT|O_EXCL, 0600) = 8
> close(8)                                = 0
> brk(0x8061000)                          = 0x8061000
> access("/usr/lib/gcc-lib/i386-linux/2.95.3/cpp0", X_OK) = 0
> vfork()                                 = 8883
> --- SIGCHLD (Child exited) ---
> wait4(-1, 0xbfffee98, 0, NULL)          = -1 ECHILD (No child 
> processes)
> write(2, "gcc: ", 5)                    = 5
> write(2, "Internal compiler error in `exec"..., 229) = 229
> write(2, "\n", 1)                       = 1
> [...]
> 
> whereas when run from the command line you get this:
> 
> [...]
> open("/tmp/ccLPisEf.i", O_RDWR|O_CREAT|O_EXCL, 0600) = 4
> close(4)                                = 0
> access("/usr/lib/gcc-lib/i386-linux/2.95.3/cpp0", X_OK) = 0
> vfork()                                 = 8920
> --- SIGCHLD (Child exited) ---
> wait4(-1, [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 8920
> brk(0x8061000)                          = 0x8061000
> access("/tmp", R_OK|W_OK|X_OK)          = 0
> [...]
> 
> In both cases the preprocessor exits before gcc reaches the wait4 call
> (SIGCHLD is reveived before wait4 is called).  The difference is that
> in the first case wait4() unexpectedly returns ECHILD instead of the
> child's pid.
> 
> The hunch is that SIGCHLD get somewhat ignored in the first
> case and not in the second.  Greping for SIGCHLD in autogen leads
> to signalSetup() where the SIGCHLD handler is set to SIG_IGN and given
> that such signal setup is inherited by child process, this feeling
> makes sense.  Indeed, reverting the SIGCHLD handler to SIG_DFL appears
> to cure the ice.

Outstanding detective work!  The problem with GCC, then, is that it
is depending on being able to receive SIGCHLD (via wait4()), but
does not ensure its delivery by checking to see if it has been set
to SIG_IGN.

2001-03-06  Bruce Korb  <bkorb@gnu.org>
            Alexandre Duret-Lutz  <duret_g@lrde.epita.fr>

	* gcc.c(main): set SIGCHLD handling to SIG_DFL so wait4() works.

Index: gcc.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/gcc.c,v
retrieving revision 1.212
diff -u -r1.212 gcc.c
--- gcc.c       2001/03/04 09:08:17     1.212
+++ gcc.c       2001/03/06 19:08:14
@@ -5517,6 +5517,7 @@
   if (signal (SIGPIPE, SIG_IGN) != SIG_IGN)
     signal (SIGPIPE, fatal_error);
 #endif
+  (void)signal (SIGCHLD, SIG_DFL);
 
   argbuf_length = 10;
   argbuf = (const char **) xmalloc (argbuf_length * sizeof (const char *));