>> 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?
The lock value being 0x0deadead was a near certainty, since that's what lock - the function - writes when trying to acquire it. It probably had the wrong value to begin with, but that value has been lost. I missed that you were hitting a bug in cpp, not bison. My suggestion about running nm still applies, and I would take Erik up on his snap offer. Russ
