[9fans] Lock loop in malloc()

2011-07-25 Thread Lucio De Re
While attempting to compile Bison (yeah, still gnawing at that bone!) I have managed to jam cpp more or less solid. That's compiling scan-code-c.c which reduces to compiling scan-code.c. However, it does not seem to be Bison that's at fault: it seems that an invocation of alloc() tries to set a

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

2011-07-25 Thread Russ Cox
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

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

2011-07-25 Thread Lucio De Re
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

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

2011-07-25 Thread Russ Cox
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

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

2011-07-25 Thread erik quanstrom
Following Erik's direction, it seems that the lock value is 0x0deadead, btw, there appears to be a typo in /sys/src/libc/386/tas.s. it should be spelled to match other arches. for some reason all other arches use 0xdeaddead. unfortunately, pool also uses 0xdeaddead so this typo is

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

2011-07-25 Thread Russ Cox
Following Erik's direction, it seems that the lock value is 0x0deadead, btw, there appears to be a typo in /sys/src/libc/386/tas.s.  it should be spelled to match other arches.  for some reason all other arches use 0xdeaddead. unfortunately, pool also uses 0xdeaddead so this typo is

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

2011-07-25 Thread erik quanstrom
well, this was a fun little bug. i downloaded bison and within a few minutes i'd narrowed the problem down to lib/c-ctype.h. and it only took another minute to isolate this as the problem statement. #if (' ' == 32) ('!' == 33) ('' == 34) ('#' == 35) \ ('%' == 37) ('' == 38) ('\'' ==

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

2011-07-25 Thread erik quanstrom
patch submitted. /n/sources/patch/cppbigif - erik

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

2011-07-25 Thread Russ Cox
no one appreciates nm. 1b1b8 B outbuf 1f1b8 b nbuf$1 1f1e0 b _dtoalk 1f1e8 B ops 1f268 B ifsatisfied 1f2e8 B _stdiolk 1f2f8 B sbrkmempriv

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

2011-07-25 Thread erik quanstrom
On Mon Jul 25 21:57:56 EDT 2011, r...@swtch.com wrote: no one appreciates nm. 1b1b8 B outbuf 1f1b8 b nbuf$1 1f1e0 b _dtoalk 1f1e8 B ops 1f268 B ifsatisfied 1f2e8 B _stdiolk 1f2f8 B sbrkmempriv nice. - erik