Re: emacs from head segfaults when run with -nw

[Eli Zaretskii]

> From: "Alfred M. Szmidt" <address@hidden>
> CC: address@hidden
> Date: Mon, 05 Apr 2010 09:34:59 -0400
> 
>    > When I start emacs with -nw, it segfaults, if I run with -Q it
>    > segfaults in a different place,
> 
>    Does this still happen with current bzr, and after you make a clean
>    bootstrap?  If so, could you please post a backtrace from the
>    segfault you get in "emacs -Q"?
> 
> Tried a clean bootstrap today, still get the segfault with -nw -Q:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x081692bd in mark_object (arg=-7552029) at alloc.c:5595
> 5595        if (XMISCANY (obj)->gcmarkbit)
> (gdb) bt full
> #0  0x081692bd in mark_object (arg=-7552029) at alloc.c:5595
>         obj = -7552029
>         cdr_count = <value optimized out>

Thanks.  It's different from what I see, but given that this seems to
be a Heisenbug (it disappears in a non-optimized build), perhaps it is
not surprising.

Can you see if this is the first GC since startup?  It is for me: if
I set a breakpoint in Fgarbage_collect, it breaks only once, and if I
let Emacs continue from there, it crashes in a subroutine of GC.

Also, do you get the crash in a non-optimized (-O0) build?  It's hard
to do anything with all those "value optimized out" variables.

If a non-optimized build does not crash, the only way I know of to
find out which data structure is invalid is by stepping with GDB
through a non-optimized build, trying to match the frames and local
variables that do appear in the backtrace of the crashed Emacs, and
compare the values between the optimized and non-optimized builds to
see what got corrupted.

In my case, I found so far that one of the submaps of
Buffer-menu-mode-map is corrupted (a NULL pointer):

  #2  0x01068682 in mark_char_table (ptr=0x2fee200) at alloc.c:5393
  5393                mark_char_table (XVECTOR (val));
  (gdb) p *ptr
  $33 = {
    size = 3222274066,
    next = 0x2ff3000,
    contents = {4}
  }
  (gdb) p ptr->contents[0]
  $34 = 4
  (gdb) p size
  $35 = 18
  (gdb) p ptr->contents[1]
  $36 = 0
  (gdb) p ptr->contents[2]
  $37 = 50252549
  (gdb) xtype
  Lisp_Vectorlike
  PVEC_SUB_CHAR_TABLE
  (gdb) xvector
  $38 = (struct Lisp_Vector *) 0x0       <<<<<<<<<<<<<<<<
  Cannot access memory at address 0x0    <<<<<<<<<<<<<<<<
  (gdb)

whereas in a non-optimized build, the same submap seems to be okay:

  #1  0x0102b3f0 in mark_char_table (ptr=0x3019200) at alloc.c:5393
  5393                mark_char_table (XVECTOR (val));
  (gdb) p size
  $31 = 18
  (gdb) p i
  $32 = 2
  (gdb) p ptr->contents[0]
  $33 = 4
  (gdb) p ptr->contents[1]
  $34 = 0
  (gdb) p ptr->contents[2]
  $35 = 50404101
  (gdb) xtype
  Lisp_Vectorlike
  PVEC_SUB_CHAR_TABLE
  (gdb) xvector
  $36 = (struct Lisp_Vector *) 0x3011b00
  0
  (gdb) p *$36
  $37 = {
    size = 3222274082,
    next = 0x3019200,
    contents = {8}
  }
  (gdb)