Re: Emacs 21.1.1 segmentation fault (!)

[Eli Zaretskii]

On 17 Dec 2001, Bob Halley wrote:

> It looks to me like we're dying at (x)->size:
> 
>      0x80504e0 <increment_row_positions+68>: mov    %edx,%eax
>      0x80504e2 <increment_row_positions+70>: sar    $0x1c,%eax
>      0x80504e5 <increment_row_positions+73>: cmp    $0x4,%eax
>      0x80504e8 <increment_row_positions+76>: jne    0x805050b 
> <increment_row_positions+111>
>      0x80504ea <increment_row_positions+78>: and    $0xfffffff,%edx
> PC-> 0x80504f0 <increment_row_positions+84>: mov    (%edx),%eax
>      0x80504f2 <increment_row_positions+86>: and    $0x20020000,%eax
>      0x80504f7 <increment_row_positions+91>: cmp    $0x20020000,%eax
>      0x80504fc <increment_row_positions+96>: jne    0x805050b 
> <increment_row_positions+111>
> 
> According to gdb, the value of %edx here is 0xbfffe7cc, which is not
> an invalid address, but I don't believe this is the correct value of
> %edx at the time of the fault since gdb's "info reg" reports the same
> value for all frames; I think that's actually the frame 0 value and
> that the value at the time of the fault is not available.  Bummer!

One idea to overcome this difficulty is to look at the assembly code
prior to the fragment you've shown and see where did the value of EDX
come from.  Eventually, you will find some variable that is not in a
register, at which point you could compute the value of EDX using
GDB's expression evaluation.

> So, all I can say is that it looks like something is trashing
> 
>         row->glyphs[area][i].object

If worse comes to worst, you could walk all the row->glyph structures
(which are global data structures, so you should be able to display
them from any frame), and find the offending .object member.