Re: Crash in show_busy_cursor.

[Jason Rumney]

Hmm, perhaps gdb is reporting a false value for f due to it being kept
in a register?

Eli Zaretskii <address@hidden> writes:

> 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.


I have no experience with Sparc assembly language, so I cannot tell
what is happening here exactly. Can anyone figure it out?
Unfortunately ddd has dumped core over the top of this core file now,
and I cannot reproduce this (I can't even get this show_busy_cursor to
be called when running under the debugger), so I cannot get any more
information (like register values etc).

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.

/usr/include/X11/IntrinsicP.h contains the following if it helps:

    #define XtWindow(widget)    ((widget)->core.window)


>From backtrace:

 [3] show_busy_cursor(), at 0x9981c  (marked with "==>")


Dump of assembler code from 0x99768 to 0x99868:
    0x99768 <show_busy_cursor>: save  %sp, -200, %sp
    0x9976c <show_busy_cursor+4>:       sethi  %hi(0x233c00), %o0
    0x99770 <show_busy_cursor+8>:       sethi  %hi(0x233c00), %o1
    0x99774 <show_busy_cursor+12>:      ld  [ %o1 + 0x300 ], %o1        ! 
0x233f00 <busy_cursor_shown_p>
    0x99778 <show_busy_cursor+16>:      cmp  %o1, 0
    0x9977c <show_busy_cursor+20>:      bne  0x99900 <show_busy_cursor+408>
    0x99780 <show_busy_cursor+24>:      clr  [ %o0 + 0x2f0 ]
    0x99784 <show_busy_cursor+28>:      sethi  %hi(0x266000), %o2
    0x99788 <show_busy_cursor+32>:      ld  [ %o2 + 0x1e0 ], %o0        ! 
0x2661e0 <interrupt_input_blocked>
    0x9978c <show_busy_cursor+36>:      sethi  %hi(0x263400), %o1
    0x99790 <show_busy_cursor+40>:      ld  [ %o1 + 0x8c ], %l1 ! 0x26348c 
<Vframe_list>
    0x99794 <show_busy_cursor+44>:      inc  %o0
    0x99798 <show_busy_cursor+48>:      st  %o0, [ %o2 + 0x1e0 ]
    0x9979c <show_busy_cursor+52>:      sra  %l1, 0x1c, %o0
    0x997a0 <show_busy_cursor+56>:      cmp  %o0, 5
    0x997a4 <show_busy_cursor+60>:      bne  0x99898 <show_busy_cursor+304>
    0x997a8 <show_busy_cursor+64>:      sethi  %hi(0x233c00), %o1
    0x997ac <show_busy_cursor+68>:      sethi  %hi(0xffffc00), %o0
    0x997b0 <show_busy_cursor+72>:      or  %o0, 0x3ff, %l2     ! 0xfffffff
    0x997b4 <show_busy_cursor+76>:      sethi  %hi(0x4000), %l3
    0x997b8 <show_busy_cursor+80>:      and  %l1, %l2, %o0
    0x997bc <show_busy_cursor+84>:      ld  [ %o0 ], %o0
    0x997c0 <show_busy_cursor+88>:      and  %o0, %l2, %l0
    0x997c4 <show_busy_cursor+92>:      ld  [ %l0 + 0xb4 ], %o0
    0x997c8 <show_busy_cursor+96>:      cmp  %o0, 1
    0x997cc <show_busy_cursor+100>:     bne  0x99880 <show_busy_cursor+280>
    0x997d0 <show_busy_cursor+104>:     and  %l1, %l2, %o0
    0x997d4 <show_busy_cursor+108>:     ld  [ %l0 + 0xb8 ], %o2
    0x997d8 <show_busy_cursor+112>:     ld  [ %o2 + 0x94 ], %o0
    0x997dc <show_busy_cursor+116>:     sethi  %hi(0x80000000), %o1
    0x997e0 <show_busy_cursor+120>:     or  %o0, %o1, %o0
    0x997e4 <show_busy_cursor+124>:     st  %o0, [ %o2 + 0x94 ]
    0x997e8 <show_busy_cursor+128>:     ld  [ %l0 + 0xb8 ], %o1
    0x997ec <show_busy_cursor+132>:     ld  [ %o1 + 0x90 ], %o0
    0x997f0 <show_busy_cursor+136>:     cmp  %o0, 0
    0x997f4 <show_busy_cursor+140>:     bne,a   0x9985c <show_busy_cursor+244>
    0x997f8 <show_busy_cursor+144>:     ld  [ %l0 + 0xb8 ], %o0
    0x997fc <show_busy_cursor+148>:     ld  [ %o1 + 0x8c ], %o0
    0x99800 <show_busy_cursor+152>:     st  %o0, [ %fp + -24 ]
    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
    0x99820 <show_busy_cursor+184>:     mov  %o4, %o5
    0x99824 <show_busy_cursor+188>:     clr  [ %sp + 0x5c ]
    0x99828 <show_busy_cursor+192>:     clr  [ %sp + 0x60 ]
    0x9982c <show_busy_cursor+196>:     mov  2, %o2
    0x99830 <show_busy_cursor+200>:     st  %o2, [ %sp + 0x64 ]
    0x99834 <show_busy_cursor+204>:     clr  [ %sp + 0x68 ]
    0x99838 <show_busy_cursor+208>:     st  %l3, [ %sp + 0x6c ]
    0x9983c <show_busy_cursor+212>:     add  %fp, -80, %o2
    0x99840 <show_busy_cursor+216>:     st  %o2, [ %sp + 0x70 ]
    0x99844 <show_busy_cursor+220>:     clr  %o2
    0x99848 <show_busy_cursor+224>:     call  0x230dbc <XCreateWindow>
    0x9984c <show_busy_cursor+228>:     mov  %o2, %o3
    0x99850 <show_busy_cursor+232>:     ld  [ %l0 + 0xb8 ], %o1
    0x99854 <show_busy_cursor+236>:     st  %o0, [ %o1 + 0x90 ]
    0x99858 <show_busy_cursor+240>:     ld  [ %l0 + 0xb8 ], %o0
    0x9985c <show_busy_cursor+244>:     ld  [ %o0 + 0x90 ], %o1
    0x99860 <show_busy_cursor+248>:     ld  [ %o0 + 0xdc ], %o0
    0x99864 <show_busy_cursor+252>:     call  0x23117c <XMapRaised>
End of assembler dump.

 
> ??? 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,
so provided FRAME_X_P is only used where the frame being a NULL
pointer is a serious error, there is nothing to be gained by silently
failing the test in this case.

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

They haven't been called yet, so this (which is what I was thinking of
before) is not the problem.

> 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.

If I can find a way to repeat this problem, I will try it.


-- 
Jason Rumney <address@hidden>
AT&T Labs (Redditch, UK)