Subject: bug#12839: 24.3.50; Emacs aborts in GC

From: Eli Zaretskii <[email-masked]>
Date: Fri, 09 Nov 2012 00:05:28 +0200

> Date: Thu, 08 Nov 2012 19:12:19 +0200
> From: Eli Zaretskii <[email-masked]>
> 
> With the current trunk, the first GC in the "emacs -Q" session aborts.
> It doesn't matter what triggers the GC.  The backtrace is below.  Let
> me know if I can help finding the problem.
> 
>   #1  0x01233dad in emacs_abort () at w32fns.c:7766
>   #2  0x0100139c in terminate_due_to_signal (sig=22, backtrace_limit=2147483647)
>       at emacs.c:345
>   #3  0x01021d64 in die (
>       msg=0x154362c "assertion failed: (tmp) < VECTOR_MAX_FREE_LIST_INDEX",
>       file=0x1542dd1 "alloc.c", line=2864) at alloc.c:6483
>   #4  0x0101b1a8 in sweep_vectors () at alloc.c:2864

Looks like I'm talking to myself here, but on the faint hope that
someone does or will read this, here's some data:

  (gdb) r -Q
  Starting program: D:\gnu\bzr\emacs\trunk\src\oo\i386\emacs.exe -Q
  [New Thread 7964.0x1eac]
  [New Thread 7964.0x1c24]
  [New Thread 7964.0xdf0]

  alloc.c:2864: Emacs fatal error: assertion failed: (tmp) < VECTOR_MAX_FREE_LIST_INDEX

  Breakpoint 1, terminate_due_to_signal (sig=22, backtrace_limit=2147483647)
      at emacs.c:318
  318       signal (sig, SIG_DFL);
  (gdb) up
  #1  0x01021d64 in die (
      msg=0x154362c "assertion failed: (tmp) < VECTOR_MAX_FREE_LIST_INDEX",
      file=0x1542dd1 "alloc.c", line=2864) at alloc.c:6483
  6483      terminate_due_to_signal (SIGABRT, INT_MAX);
  (gdb) up
  #2  0x0101b1a8 in sweep_vectors () at alloc.c:2864
  2864                      SETUP_ON_FREE_LIST (vector, total_bytes, tmp);
  (gdb) l
  2859                       space was coalesced into the only free vector.  */
  2860                    free_this_block = 1;
  2861                  else
  2862                    {
  2863                      int tmp;
  2864                      SETUP_ON_FREE_LIST (vector, total_bytes, tmp);
  2865                    }
  2866                }
  2867            }
  2868
  (gdb) p total_bytes
  $1 = 223420624
  (gdb) p vector->header_size
  There is no member named header_size.
  (gdb) p vector->header.size
  $2 = 1166225408
  (gdb) p vector->header
  $3 = {
    size = 1166225408
  }

Looks like this vector is complete garbage.  And the same goes for the
first one on vector_blocks:

  (gdb) p (struct Lisp_Vector *)vector_blocks->data
  $5 = (struct Lisp_Vector *) 0x357e000
  (gdb) p ((struct Lisp_Vector *)vector_blocks->data)->header
  $6 = {
    size = 1275068420
  }

Also, a different, but related, crash:

  emacs -Q
  C-x 3
  M-x set-variable RET auto-hscroll-mode RET nil RET

This yields the following crash:

  Program received signal SIGSEGV, Segmentation fault.
  0x010201e5 in mark_object (arg=1325400077) at alloc.c:5722
  5722            if (VECTOR_MARKED_P (ptr))
  (gdb) l
  5717        case Lisp_Vectorlike:
  5718          {
  5719            register struct Lisp_Vector *ptr = XVECTOR (obj);
  5720            register ptrdiff_t pvectype;
  5721
  5722            if (VECTOR_MARKED_P (ptr))
  5723              break;
  5724
  5725    #ifdef GC_CHECK_MARKED_OBJECTS
  5726            m = mem_find (po);
  (gdb) p ptr
  $1 = (struct Lisp_Vector *) 0x4f000008
  (gdb) p *ptr
  Cannot access memory at address 0x4f000008

I hope this will make sense to someone.