Re: SIGSEGV -- redisplay bug

[Alex Schroeder]

And it happened again...

Program received signal SIGSEGV, Segmentation fault.
0x080506fd in increment_row_positions (row=0x93bc684, delta=0, delta_bytes=0) 
at dispnew.c:1188
1188          if (BUFFERP (row->glyphs[area][i].object)
(gdb) l
1183      MATRIX_ROW_END_BYTEPOS (row) += delta_bytes;
1184
1185      /* Increment positions in glyphs.  */
1186      for (area = 0; area < LAST_AREA; ++area)
1187        for (i = 0; i < row->used[area]; ++i)
1188          if (BUFFERP (row->glyphs[area][i].object)
1189              && row->glyphs[area][i].charpos > 0)
1190            row->glyphs[area][i].charpos += delta;
1191
1192      /* Capture the case of rows displaying a line end.  */

Richard Stallman <address@hidden> writes:

>     1185      /* Increment positions in glyphs.  */
>     1186      for (area = 0; area < LAST_AREA; ++area)
>     1187        for (i = 0; i < row->used[area]; ++i)
>     1188          if (BUFFERP (row->glyphs[area][i].object)
>     1189              && row->glyphs[area][i].charpos > 0)
>     1190            row->glyphs[area][i].charpos += delta;
>     1191
>     1192      /* Capture the case of rows displaying a line end.  */
>     (gdb) p area
>     $1 = 4011656
>
> It looks impossible to me--at least if there is no bizarre form of
> aliasing.
>
> Could you examine the data and verify that there was no aliasing
> that would have caused clobberage of the value of area?
> Where is area stored?  (Do `i ad area'.)
>
> Would  row->glyphs[area][i].charpos  ever have aliased with area?

I know nothing of aliasing...  so i don't know what you question is
about.  Anyway, I can try i ad area:

(gdb) p area
$1 = 4008192
(gdb) i ad area
Symbol "area" is a variable in register edx.
(gdb) i ad i
Symbol "i" is a variable in register esi.

I don't know what to do with this.  I searched the index of the gdb
manual for the term alias (using the i command) and did not find
anything.  Where can I learn more about the problem you are
suspecting?

Alex.