GNU bug report logs -
#12839
24.3.50; Emacs aborts in GC
Previous Next
Reported by: Eli Zaretskii <eliz <at> gnu.org>
Date: Thu, 8 Nov 2012 17:25:01 UTC
Severity: normal
Found in version 24.3.50
Done: Glenn Morris <rgm <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> Date: Thu, 08 Nov 2012 19:12:19 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> 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.
This bug report was last modified 12 years and 275 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.