Re: 22.0.50 SEGFAULT

[JD Smith]

On Sun, 31 Jul 2005 01:01:53 +0200, Kim F. Storm wrote:

> JD Smith writes:
> 
> 
>>>> GNU Emacs 22.0.50.3 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
>>>> of 2005-07-14 on turtle.as.arizona.edu
> 
> Sorry, but I cannot see any reason why it fails from the data you sent me.
> 
> Something tells me that the gdb output isn't quite right, as the
> references (buffer) object is the same for all of these:
> 
>   p row->glyphs[area][i-1]  (if i > 0)
>   p row->glyphs[area][i]
>   p row->glyphs[area][i+1]
> 
> .. so why would it fail on [i] but not on [i-1].
> 
> 
> My only suggestion to get to the bottom of this is to build emacs without
> optimizations like this:
> 
> /configure "CFLAGS=-g -O0"    (that's letter O followed by digit 0). make
> 
> [
> alternatively, you can:
> - cd src/
> - edit Makefile changing CFLAGS= line to read CFLAGS=-g -O0 - rm *.o
> - make emacs
> ]
> 
> and see if that makes a difference [it could actually result in finding a
> different position of the crash...]

Thanks, Kim.  I can confirm that the OBJECT field of basically
everything around the crash position is the same:

(gdb) p row->glyphs[area][0].object
$38 = 145085668
(gdb) p row->glyphs[area][1].object
$39 = 145085668
(gdb) p row->glyphs[area][2].object
$40 = 145085668
(gdb) p row->glyphs[area][3].object
$41 = 145085668
(gdb) p row->glyphs[area][4].object
$42 = 145085668
(gdb) p row->glyphs[area][5].object
$45 = 145085668
(gdb) p row->glyphs[area][6].object
$46 = 145085668
(gdb) p row->glyphs[area][7].object
$47 = 145085668
(gdb) p row->glyphs[area][20].object
$48 = 145085668
(gdb) p row->glyphs[area][25].object
$49 = 145085668
(gdb) p row->glyphs[area][35].object
$50 = 145085668
(gdb) p row->glyphs[area][50].object
$51 = 145085668

I'm not sure if this is significant (or expected in real situations).
The CHARPOS does indeed increment:

(gdb) p row->glyphs[area][4].charpos
$53 = 2518
(gdb) p row->glyphs[area][50].charpos
$54 = 2564

I also don't see why [i-1] succeeds and [i] fails if they point to the
same exact object, and if this stanza is the offender:

        ((void) 0,(struct Lisp_Vector *)
                ((int) ((row->glyphs[area][i].object) &
                         ~((((int) 1) << 3) - 1))))->size

I'll rebuild emacs without optimization and see if the crash recurs
and makes more sense this time.

JD