From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 25 Jul 2011 17:17:46 +0200 From: Lucio De Re To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20110725151746.GD27739@fangle.proxima.alt.za> References: <20110725135837.GC27739@fangle.proxima.alt.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [9fans] Lock loop in malloc() Topicbox-Message-UUID: 05fbbf0a-ead7-11e9-9d60-3106f5b1d025 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