Re: Failing test case 67 Fatal errors but M4 continues producing output

[Joel E. Denny]

I'm adding bug-gnulib in case they have already seen this problem with 
create_pipe_bidi.

On Fri, 9 Apr 2010, Petr Machata wrote:

> I was rebasing the bison package to latest stable (2.4.2) in Fedora
> distribution, and found out that the test case 67 fails.  I'm attaching
> testfile.log.

Here's the attachment....

> #                             -*- compilation -*-
> 67. skeletons.at:308: testing ...
> ./skeletons.at:320: perl gen-skel.pl > skel.c || exit 77
> ./skeletons.at:328: VALGRIND_OPTS="$VALGRIND_OPTS --leak-check=summary 
> --show-reachable=no"; export VALGRIND_OPTS; bison input.y
> --- - 2010-04-07 19:01:39.306913000 -0400
> +++ /builddir/build/BUILD/bison-2.4.2/tests/testsuite.dir/at-groups/67/stderr 
> 2010-04-07 19:01:39.000000000 -0400
> @@ -1,2 +1,4 @@
>  input.y: fatal error: too many arguments for @output directive in skeleton
> +/usr/bin/m4:./skel.c:175: ERROR: copying inserted file: Broken pipe
> +/usr/bin/m4: write error
>  
> 67. skeletons.at:308: 67. Fatal errors but M4 continues producing output 
> (skeletons.at:308): FAILED (skeletons.at:328)

Thanks for the report.  One of the goals of Bison 2.4.2 was to avoid m4's 
report of a broken pipe.  To do so, we started using gnulib's 
create_pipe_bidi, and that worked for me, but apparently it did not work 
in general.

Here's the invocation of create_pipe_bidi:

  pid = create_pipe_bidi ("m4", m4, (char **)(void*)argv, false, true,
                          true, filter_fd);

The scenario is that Bison sometimes reaches a fatal error and thus 
invokes exit without reading all of the m4 output and without invoking 
wait_subprocess.  I thought that create_pipe_bidi is supposed to make sure 
that the m4 subprocess is killed when Bison invokes exit, and I thought 
that would keep m4 from managing to receive an EPIPE, but apparently my 
understanding is wrong somewhere.

> While the fail seems to be deterministic in the Fedora
> build system, I was unable to reproduce it locally.

Before switching to create_pipe_bidi, I had observed a race condition.  
That is, I could run a test for this problem on the same system many times 
in a row, and it would fail only some of the time.  This race condition 
might still be there.

> The build system uses RHEL 5 as a 
> base system, and builds the package in mock chroot with given Fedora 
> release.  I nailed the exact package versions inside mock, and got the 
> right kernel version on the host system, but even then I was 
> unsuccessful in reproducing the problem.  Dunno what trips it up.
> 
> I'm not quite sure how useful this bug report will be, but oh well.  At
> least now you know it happened in case more hazy reports arrive.

If no one at bug-gnulib has a better suggestion, I might try the simple 
fix of draining the m4 output pipe before invoking exit upon a fatal error 
in Bison.  Or maybe I can change the disposition for SIGPIPE to terminate 
so that m4 cannot report the EPIPE.