[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Failing test case 67 Fatal errors but M4 continues producing output
From: |
Petr Machata |
Subject: |
Re: Failing test case 67 Fatal errors but M4 continues producing output |
Date: |
Mon, 12 Apr 2010 16:18:35 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3 |
11.04.2010 20:40, Joel E. Denny wrote:
> On Sun, 11 Apr 2010, Bruno Haible wrote:
>
>> The code in bison-2.4.2/src/output.c looks fine.
>
> Thanks for confirming.
>
>> Can you help reproducing or debugging it, with just 2 executables: bison
>> and m4? (I.e. give a "how to reproduce" that does not involve bison's
>> testsuite? I'm not inclined to look into a 3 MB large machine generated
>> shell script.)
>
> Because I do not have access to the affected platform, I can only explain
> the actions that the failing test group performs. Petr, can you please
> confirm that the following instructions produce the problem for you?
> Recall that there may be a race condition, so run bison many times if it
> does not produce the problem at first. Also, please remind us exactly
> which platform exhibits the problem.
I saw the problem on x86_64 and x86 and didn't check any other platform.
The platform is "fedora build system". This is RHEL 5 with mock chroot
where Fedora rawhide is installed. Unfortunately I was unsuccessful
reproducing it outside the actual build system, even mimicking these
conditions down to kernel version. I don't know whether some part of
userspace of host can influence what happens in mock, but that's the
only part of the whole setup that I didn't try to mach 1:1 to build system.
The instructions that you gave indeed do reproduce the problem. The
build log, should you be interested, is here:
http://koji.fedoraproject.org/koji/getfile?taskID=2110920&name=build.log
Here's hoping that it's accessible without some sort of registration.
The build log will be wiped out automatically in near future, but it
should hopefully stay up a week or so.
Relevant quote:
> + echo =xxx=================================================================
> + ./tests/bison /builddir/build/SOURCES/input.y
> /builddir/build/SOURCES/input.y: fatal error: too many arguments for @output
> directive in skeleton
> + :
> -xxx-----------------------------------------------------------------
> /usr/bin/m4:/builddir/build/SOURCES/./skel.c:175: ERROR: copying inserted
> file: Broken pipe
> + echo -xxx-----------------------------------------------------------------
> /usr/bin/m4: write error
> + make check
> make check-recursive
PM
P.S. I seriously wonder whether it's worth it to hunt this esoteric bug.
(Especially given that it was confirmed that the code is written
correctly.) As I said, it's essentially impossible to reproduce outside
that very specific setup, meaning user impact low, and it's not like
this is a major breaker.
signature.asc
Description: OpenPGP digital signature
Re: Failing test case 67 Fatal errors but M4 continues producing output, Petr Machata, 2010/04/12