From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20110725151746.GD27739@fangle.proxima.alt.za> References: <20110725135837.GC27739@fangle.proxima.alt.za> <20110725151746.GD27739@fangle.proxima.alt.za> Date: Mon, 25 Jul 2011 12:12:35 -0400 Message-ID: Subject: Re: [9fans] Lock loop in malloc() From: Russ Cox To: lucio@proxima.alt.za, Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Topicbox-Message-UUID: 0613d554-ead7-11e9-9d60-3106f5b1d025 >> 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). =C2=A0Assuming 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. =C2=A0I'll need to dig into cpp, then. =C2=A0Are 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