Re: Updating from bison 1.24 to 2.4.1

On Jul 23, 8:08 am, Tuggi <soeren.zimmerm...@sef.de> wrote:
> Hi all,
>
> I've got a problem when trying to update bison from version 1.24 to
> 2.4.1. Here it goes: ...


> When I generate a c-file from our bison definiton file (*.y) with the
> old version of bison (1.24) and use this c-file within my application,
> all works fine and the application runs as usual.
>
> Then I use the new bison version (2.4.1) with the same *.y-file.
> Running bison and compling my application with the generated c-file
> works with no errors. But running the new built application causes
> trouble: It crashes! Calling yyparse() now leads to an
> EAccessViolation-exception. Calling yyparse() twice even terminates
> the application with an "Abnormal program termination".
>
> Is there something like a compatibility mode when using bison? Or any
> other things to regard?
>
> I also want to mention that generating the c-file causes 1 shift/
> reduce and 2 reduce/reduce conflicts. I didn't find the reason yet,
> because I'm engaged in the flex/bison code for a short time. Despite
> of these warnings the c-file generated with the old bision (1.24)
> works. ...


> [I suggested that this problem usually means that there are pointer
> bugs in user code that happened not to crash until the new version
> of bison moved the data around. Debug them the same way one debugs
> any other pointer problems. -John]


John is right. Its a 99.99% chance you have some kind of memory
layout-dependent bug that has been exposed by the different memory
layout of the newer bison parser skeleton. The other 0.01% chance is
that you've actually discovered a bug in bison, but the procedure to
follow will be the same either way.


Look at this as a good (though painful) thing. The memory bug could
have easily caused a really insidious problem with the old bison. Now
you have an opportunity to squash it.


John's advice is right. Get a good debugger. Catch the the fault and
dump the C stack and major data structures. Inspect for bogus values.
These are clues. If you're lucky, there will be a smoking gun: an
obviously bad value or pointer for example. Instrument this location
and run again to catch the bad write. If you're not lucky, then apply
your favorite memory access bug detection tool to see if you can catch
the bogus write that must be there. If that doesn't work, then you
are down to brute force. Disable or write test cases that avoid
chunks of your program in a binary search-like manner until you find a
minimally sized chunk where disabling and enabling causes the bug to
dis- and re-appear. Do a careful code review. Single step and/or log
writes until you find the culprit. Yada yada...


The advice to get rid of the reduce-reduce conflicts is good. These
mean your grammar is broken. But they are not the cause of your
crashes.


FWIW, the limitation with old bison results from 16-bit table
entries. Your tables got too big to be addressable with such little
indexes.

Return to the comp.compilers page.
Search the comp.compilers archives again.