> However, it does not seem to be Bison that's at fault: it seems that an > invocation of alloc() tries to set a lock and never succeeds or gives up.
It's possible that you've found a latent bug in malloc. However, that malloc has been running along pretty steadily for a decade at this point, so it wouldn't be my first guess. My first guess would be that something in Bison or in the code you added has corrupted memory, so that the lock has been overwritten with garbage and therefore cannot be acquired. The address passed to lock - 0x1f2f8 in the trace - should be the address of the symbol sbrkmempriv. I assume it will be, but check (if not, there's other memory corruption). Assuming it is, that's in the bss so the most likely culprits for corruption are the symbols near it: run nm | sort and look around. Another thing to do would be to take the bison code you are compiling to a Linux box and run it under valgrind. Russ
