Re: Crash in show_busy_cursor.

[Eli Zaretskii]

> From: Jason Rumney <address@hidden>
> Date: Wed, 29 Nov 2000 05:29:01 -0800 (PST)
> 
> I have no experience with Sparc assembly language

Me neither.

> My interpretation is that either f or output_data.x is being stored in
> %o0, and it is two levels of dereferencing below this
> (in the toolkit version of FRAME_OUTER_WINDOW(f)?) that is causing the
> SEGV.

Yes, it looks like that.

> /usr/include/X11/IntrinsicP.h contains the following if it helps:
> 
>     #define XtWindow(widget)  ((widget)->core.window)

So it looks like f->output_data.x->widget.core is garbled, because
this snippet:

>     0x99804 <show_busy_cursor+156>:   ld  [ %l0 + 0xb8 ], %o0
>     0x99808 <show_busy_cursor+160>:   ld  [ %o0 + 0xdc ], %o1
>     0x9980c <show_busy_cursor+164>:   ld  [ %o0 + 0x3c ], %o2
>     0x99810 <show_busy_cursor+168>:   sethi  %hi(0x7c00), %o4
>     0x99814 <show_busy_cursor+172>:   ld  [ %o1 + 8 ], %o0
>     0x99818 <show_busy_cursor+176>:   or  %o4, 0x100, %o4
> ==> 0x9981c <show_busy_cursor+180>:   ld  [ %o2 + 0x60 ], %o1

loads into %o1 something that stays there until XCreateWindow is
called.  So %o1 probably holds f->output_data.x->widget->core.window,
in which case %o2 should be f->output_data.x->widget->core.

(You should be able to verify that by checking whether core.window is
at offset 0x60 from core.)

This explains why the code before that line didn't crash: widget was
not dereferenced by any line before that.

I'm clueless as to why core could be garbled in this case; perhaps
SIGALRM interrupted the toolkit while it was creating the widget->core
object (whatever that is).

> > ??? 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.
> 
> No, even W32 will give a protection violation in these circumstances,

Sorry, I had in mind the DPMI server built into Windows (that's what
DJGPP uses), which doesn't support a function to unmap a page from a
program's address space, so NULL pointer protection doesn't work in
DJGPP programs running on Windows.  This, of course, is irrelevant for
native Windows applications, only for the parts of the Windows kernel
which use DPMI.