bug-gnulib
[Top][All Lists]
Advanced

[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.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]