Re: Crash in show_busy_cursor.

[Eli Zaretskii]

On Wed, 29 Nov 2000, Jason Rumney wrote:

> Having given up on dbx and installed gdb, I found that the crash I
> reported earlier occurred on the line marked "==>", with f = 0.
> Since earlier lines have successfully dereferenced f, I suspect some
> stack corruption has occurred, possibly due to non-reentrant system
> library functions as Eli suggested.

I would suggest to examine the machine instruction which crashed and the 
instructions which were executed before that, since the entry to 
show_busy_cursor, if you didn't do that already.  It is possible that the 
crashed instruction is actually the first one to dereference f, and that 
the compiler optimizations and bugs/misfeatures in how the compiler  
produces source line info used by GDB confuse the debugger into showing 
the wrong source line.

> Note though that it is possible for a NULL pointer to pass the
> FRAME_X_P test if the right byte just happens to be found at that
> location

??? This isn't Windows, is it?  FRAME_X_P dereferences f, so on any 
decent system it will immediately GP Fault if f is a NULL pointer.

Assuming that you check (or checked already) that previous dereferences 
of f worked, and only this one segfaulted, I would be hard-pressed to 
explain this particular case by library reentrancy.  The problem is that 
a signal handler's data is pushed onto the stack _above_ any librray 
function that happened to run when the signal fired.  Since no other 
library function is called inside show_busy_cursor, I don't see how the 
library could corrupt the stack, especially half-way through 
show_busy_cursor's code.  Hmm...

Unless XCreateWindow (or other X* functions called for previous frames in 
the list) somehow corrupted the stack, that is.

Does GDB support hardware-assisted watchpoints on that platform?  If so, 
you could try setting a watchpoint on the frame which causes GPF and see 
who zeroes it out.