On Mon, Jul 25, 2011 at 10:42:11AM -0400, Russ Cox wrote: > > > 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. > Well, there has to be a problem, I agree that malloc() is used too extensively in Plan 9 to only reveal a fault at this time. The same may be said of cpp, but it's more likely that something evil has been lurking in there. I really hope that it is not something I have done that causes the problem, but I really can't see how that would be possible without cpp's cooperation.
> 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. > Following Erik's direction, it seems that the lock value is 0x0deadead, so I will start with the premise that a problem has been detected, but not fatally. I'll need to dig into cpp, then. Are there known limits in cpp's input sizes? > Another thing to do would be to take the bison code > you are compiling to a Linux box and run it under > valgrind. > I have heard good reports regarding valgrind, but it is totally foreign to me, I'lll resort to that when I have no alternative left. Thanks for the advice, please forgive me for not following it immediately. ++L
