Re: Emacs 21.1.1 segmentation fault (!)

[Bob Halley]

Richard Stallman <rms@gnu.org> writes:

> Since this was a seg fault, can you see anything in the data referenced
> in this code
> 
>   /* Increment positions in glyphs.  */
>   for (area = 0; area < LAST_AREA; ++area)
>     for (i = 0; i < row->used[area]; ++i)
>       if (BUFFERP (row->glyphs[area][i].object)
>         && row->glyphs[area][i].charpos > 0)
>       row->glyphs[area][i].charpos += delta;

> Can you find the invalid address that caused the seg fault?
> Studying the code at the assembler level might help.

Hmm... I'm not getting completely consistent output from gdb; it may
be that the code optimization confused things.  E.g. the value of
row->glyphs[area][i].object is 0x3849F31C.  The type of this value is
0x03, which is not Lisp_Vectorlike, and yet the assembly code appears
to indicate that we're dying inside of an evalation of code generated
by

#define BUFFERP(x) PSEUDOVECTORP (x, PVEC_BUFFER)

which is:

/* True if object X is a pseudovector whose code is CODE.  */
#define PSEUDOVECTORP(x, code)                                  \
  (VECTORLIKEP (x)                                              \
   && (((XVECTOR (x)->size & (PSEUDOVECTOR_FLAG | (code))))     \
       == (PSEUDOVECTOR_FLAG | (code))))

*after* we've passed the VECTORLIKEP() test.

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!

So, all I can say is that it looks like something is trashing

        row->glyphs[area][i].object

Let me know if I can help more.  If I knew a way to reproduce the bug,
I'd rebuild without optimization and see what happened, but I don't
know how to trigger the bug.

Regards,

/Bob