Re: Mac OSX running Carbon crash with today's CVS

["Eli Zaretskii" <eliz@elta.co.il>]

> Date: Tue, 22 Apr 2003 07:39:25 -0700
> From: Gabriel Foster <gabriel@apple.com>
> 
> In the most recent case, I had just hit the enter key.

Can you cause the same crash if you type "M-x garbage-collect RET"
right after starting Emacs?

> (gdb) print tail
> $2 = (struct gcpro *) 0xbfffde20
> (gdb) print *tail->var[i]
> Cannot access memory at address 0x1
> (gdb) print tail->var[i]
> Cannot access memory at address 0x1
> (gdb) print tail->var
> $3 = (volatile int *) 0x1

This is the problem, then: either tail->var or tail->nvars is garbled
(I'm guessing it's the latter).

Does anyone have a clue why this could happen on a Mac?

If no one comes up with a better idea, one way of attacking this bug
would be to put a hardware-assisted watchpoint on the nvars member,
like this:

   (gdb) watch ((struct gcpro *)0xbfffde20)->nvars

and when the watchpoint fires, look for the code that puts the
preposterously large value into nvars.  (If nvars changes its value
to something reasonable, like zero or 1, just type "cont" to let the
program resume its run.)

Before you do the above, it is highly recommended to find a simple
procedure that would predictably cause such a crash, and with the
same value of `tail', the GCPRO structure that is garbled.  Then use
that address instead of 0xbfffde20 above.

(I'm assuming that GDB on Mac OSX supports hardware-assisted
watchpoints, btw.)