Thanks. I can reproduce the problem as follows, with CVS Bison on Debian stable (with my own copy of GCC 4.1.1). It sure looks like a bug in the Bison skeleton.
It seems to be related to recent changes in the yacc.c skeleton. OK, guys, will someone who changed the skeleton recently like to look at this problem? $ cd tests $ VALGRIND_OPTS='--leak-check=full --show-reachable=yes' ./testsuite PREBISON='valgrind -q' PREPARSER='valgrind -q' -v -d 145 ## --------------------------- ## ## GNU Bison 2.3a+ test suite. ## ## --------------------------- ## 145. torture.at:474: testing ... ./torture.at:483: bison -o input.c input.y ... ./torture.at:497: $PREPARSER ./input 900 stderr: Starting parse Entering state 0 Reading a token: Next token is token WAIT_FOR_EOF () Shifting token WAIT_FOR_EOF () Entering state 1 Return for a new token: Reading a token: Next token is token WAIT_FOR_EOF () Shifting token WAIT_FOR_EOF () Entering state 1 ... Reading a token: Next token is token WAIT_FOR_EOF () Shifting token WAIT_FOR_EOF () ==14755== Invalid write of size 4 ==14755== at 0x80491D4: yypush_parse (input.c:1399) ==14755== by 0x8048B6A: yypull_parse (input.c:1126) ==14755== by 0x80498F6: main (input.y:61) ==14755== Address 0x52BFE0F0 is just below %esp. Possibly a bug in GCC/G++ ==14755== v 2.96 or 3.0.X. To suppress, use: --workaround-gcc296-bugs=yes ==14755== ==14755== Invalid write of size 2 ==14755== at 0x8048CEE: yypush_parse (input.c:1252) ==14755== by 0x8048B6A: yypull_parse (input.c:1126) ==14755== by 0x80498F6: main (input.y:61) ==14755== Address 0x52BFDC40 is not stack'd, malloc'd or (recently) free'd
