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.
