headers
Akim Demaille | 17 Jun 17:12
Picon
Picon
Picon

Re: A bit more info about hanging bison on tru64 5.1b

>>> "DG" == Didier Godefroy <dg <at> ulysium.net> writes:

 > Hello all,

Hi Didier,

 > I posted a while ago about my issue of hanging bison on more than one tru64
 > 5.1b systems.

Your mail was not unnoticed :)  Could you please try the following
tarball?  Maybe the trouble is fixed --- it includes several various
fixes.

Thanks in advance!

<URL:http://www.lrde.epita.fr/~akim/download/bison-2.4.334-4197.tar.gz>
Permalink | Reply | 11 comments |
headers
Didier Godefroy | 17 Jun 23:49

Re: A bit more info about hanging bison on tru64 5.1b

************ re-sending this message without the attachments, it came back
undelivered with them

on 6/17/09 5:12 PM, Akim Demaille at Akim.Demaille <at> lrde.epita.fr uttered the
following:

> Your mail was not unnoticed :)  Could you please try the following
> tarball?  Maybe the trouble is fixed --- it includes several various
> fixes.

Cool!

> <URL:http://www.lrde.epita.fr/~akim/download/bison-2.4.334-4197.tar.gz>

Ok, it compiles fine as well, and gets stuck on the same things during the
tests.

To compile it, I throw those in the environment:

CC=cc
CFLAGS="-std -O4 -g3 -w"
CPPFLAGS="-I/usr/local/include -pthread"
LDFLAGS="-L/usr/local/lib"
CXX=cxx
CXXFLAGS="-O4 -g3 -w -D__USE_STD_IOSTREAM"
LD_LIBRARY_PATH=/usr/local/lib

And I used those following configure options:

configure \
(Continue reading)

Permalink | Reply | 10 comments |
headers
Akim Demaille | 24 Jun 12:46
Picon
Picon
Picon
Gravatar

Re: A bit more info about hanging bison on tru64 5.1b


Le 17 juin 09 à 23:49, Didier Godefroy a écrit :

> ************ re-sending this message without the attachments, it  
> came back
> undelivered with them

Actually, it was accepted.  You attached several files, but not the  
testsuite.log file, which is the most important one.

Could you please run

	make check TESTSUITEFLAGS='-d -v 3'  </deb/null

and send the result back?  There are two sets of tests in test 3, and  
I don't know which one failed.

It will display the command that were run, typically

	bison input.y

input.y is actually tests/testsuite.dir/003/input.y.  It would be most  
useful if you could try to make it as small as possible while  
preserving the bug (eliminate each a:, b: etc. line).  To run Bison on  
the test, run

	./tests/bison tests/testsuite.dir/003/input.y

to be sure you're using the bison from the tarball.  Possibly with the  
flag --warnings=midrule-values if it's the second run that has problems.
(Continue reading)

Permalink | Reply | 9 comments |
headers
Didier Godefroy | 25 Jun 10:08

Re: A bit more info about hanging bison on tru64 5.1b

on 6/24/09 12:46 PM, Akim Demaille at akim <at> lrde.epita.fr uttered the
following:

> Actually, it was accepted.  You attached several files, but not the
> testsuite.log file, which is the most important one.

Oops!!!
Sending it now.

> Could you please run
> 
> make check TESTSUITEFLAGS='-d -v 3'  </deb/null
> 
> and send the result back?  There are two sets of tests in test 3, and
> I don't know which one failed.

Maybe the first one I guess.
I had to kill the hung process again, which is why it says the test failed.
If I leave it alone, it keeps one cpu pegged to nearly 100% forever. I've
tried leaving it a very long time before to find out for sure, it ran a good
part of a day, then overnight and then again for hours the next day and
nothing happened, I just killed that process.

> It will display the command that were run, typically
> 
> bison input.y

That's the one.
I'm attaching the testsuite.log from the 003 folder as well.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Akim Demaille | 25 Jun 13:09
Picon
Picon
Picon
Gravatar

Re: A bit more info about hanging bison on tru64 5.1b


Le 25 juin 09 à 10:08, Didier Godefroy a écrit :

> I had to kill the process here.
> And here's the out put after the kill:
>
> src/bison: subsidiary program `/usr/bin/gm4' failed

This is precious information: it is not Bison but M4 that hangs.   
Could you give me the result of /usr/bin/gm4 --version please?

> I didn't know exactly how to "eliminate" the lines a: b: and such.  
> Removing
> one line caused an error, so I did for each line the same as for the  
> b:
> line, putting comments and after adding one at a time, I ended up  
> with all
> commented:
>
> a: INT | /*INT { } INT { } INT { }*/;
> b: INT | /* empty */;
> c: INT | /*INT { $1 } INT { $<integer>2 } INT { $<integer>4 }*/;
> d: INT | /*INT { } INT { $1 } INT { $<integer>2 }*/;
> e: INT | /*INT { } INT {  } INT { $1 }*/;
> f: INT | /*INT { } INT {  } INT { $$ = $1 + $3 + $5; }*/;
> g: INT | /*INT { $<integer>$; } INT { $<integer>$; } INT { }*/;
> h: INT | /*INT { $<integer>$; } INT { $<integer>$ = $<integer>2; }  
> INT {
> }*/;
> i: INT | /*INT INT { } { $$ = $1 + $2; }*/;
(Continue reading)

Permalink | Reply | 7 comments |
headers
Didier Godefroy | 25 Jun 13:35

Re: A bit more info about hanging bison on tru64 5.1b

on 6/25/09 1:09 PM, Akim Demaille at akim <at> lrde.epita.fr uttered the
following:

>> src/bison: subsidiary program `/usr/bin/gm4' failed
> 
> This is precious information: it is not Bison but M4 that hangs.
> Could you give me the result of /usr/bin/gm4 --version please?

m4 (GNU M4) 1.4.9

That's odd, because I don't remember having any issues during m4's test
suite, it passed and didn't seem to give any troubles.
Besides, sendmail makes extensive use of m4 during install and it worked
fine.

>> And the hang still occurs.
> 
> Huh?  So you are saying that
> 
> cat >test-1.y <<EOF
> %token <integer> INT;
> %type <integer> a b c d e f g h i j k l;
> %destructor { destroy ($$); } INT a b c d e f g h i j k l;
> %%
> start:
>    'a' a { $2; } | 'b' b { $2; } | 'c' c { $2; } | 'd' d { $2; }
> | 'e' e { $2; } | 'f' f { $2; } | 'g' g { $2; } | 'h' h { $2; }
> | 'i' i { $2; } | 'j' j { $2; } | 'k' k { $2; } | 'l' l { $2; }
> ;
>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Didier Godefroy | 25 Jun 13:46

Re: A bit more info about hanging bison on tru64 5.1b

on 6/25/09 1:09 PM, Akim Demaille at akim <at> lrde.epita.fr uttered the
following:

>> src/bison: subsidiary program `/usr/bin/gm4' failed

I just tried substituting the m4, putting the tru64 m4 back in place and
disabling gm4.
What's odd is that before actually making /usr/bin/m4 (the tru64 one) into
/usr/bin/gm4 (symlinking) and trying the test again, the same thing happen
and it failed on /usr/bin/gm4 which at that moment didn't exist any more.
After symlinking /usr/bin/m4 to /usr/bin/gm4 and running the test again, it
made no difference.
It tries regardless to use gm4, even if not there, and when not there, the
behavior is the same as if it was there.

I have somewhat similar problems with some of the tests in flex's test
suite, so I'm wondering if that would be due to the same thing...

Thanks,

--

-- 
Didier Godefroy
mailto:dg <at> ulysium.net
Support anti-Spam legislation.
Join the fight http://www.cauce.org/
Permalink | Reply | 0 comments |
headers
Akim Demaille | 25 Jun 13:58
Picon
Picon
Picon
Gravatar

Re: A bit more info about hanging bison on tru64 5.1b


Le 25 juin 09 à 13:35, Didier Godefroy a écrit :

GNU M4 1.4.9?

That's not very recent.  If you can upgrade, that would be nice.   
Bison requires GNU m4, not a plain M4.

> ./tests/bison --trace=m4 test-2.y </dev/null 2>m4.log
>
> Hangs and the m4.log is actually quite short:
>
> test-2.y:6.4-14: warning: unused value: $2
>
> That's all there is in there.

That's bizarre, it means m4 didn't even start.

Could you try

> ./tests/bison --trace=m4,muscles,tools test-2.y </dev/null 2>m4.log

?

Thanks.
Permalink | Reply | 4 comments |
headers
Didier Godefroy | 25 Jun 20:54

Re: A bit more info about hanging bison on tru64 5.1b

on 6/25/09 1:58 PM, Akim Demaille at akim <at> lrde.epita.fr uttered the
following:

> GNU M4 1.4.9?
> 
> That's not very recent.  If you can upgrade, that would be nice.
> Bison requires GNU m4, not a plain M4.

Ok. I remembered upgrading m4 not so long ago. Actually it's been close to a
couple of years.
I upgraded m4 to:

m4 (GNU M4) 1.4.13

It compiled and tested ok.

>> ./tests/bison --trace=m4 test-2.y </dev/null 2>m4.log
>> 
>> Hangs and the m4.log is actually quite short:
>> 
>> test-2.y:6.4-14: warning: unused value: $2
>> 
>> That's all there is in there.
> 
> That's bizarre, it means m4 didn't even start.

That's what I thought was odd.

> Could you try
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Nuwan | 26 Jun 21:00
Picon

A bug in bison-2.4.1

Bison generated C++ code. Consist with following simple bug.
version - 2.4.1
skeleton - lalr1.cc

For every prefix & every class name it generates the same define guard
PARSER_HEADER_H, to guard the parser class. This causes to two parsers
un-usable in the same program.

Suggestion : Prefix the macro with provided class name.
--

-- 
____________________________
A.M Nuwan Abeysinghe
Permalink | Reply | 0 comments |

Gmane