Re: [9fans] Lock loop in malloc()

[Russ Cox <rsc@swtch.com>]

>> 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