[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24764: 25.1.50; Another crash in automatic gc
From: |
Eli Zaretskii |
Subject: |
bug#24764: 25.1.50; Another crash in automatic gc |
Date: |
Sat, 22 Oct 2016 18:25:17 +0300 |
> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: npostavs@users.sourceforge.net, 24764@debbugs.gnu.org
> Date: Sat, 22 Oct 2016 16:51:38 +0200
>
> I attach two other gdb sessions with backtraces. Maybe they look
> different, or they don't, I'm not good at reading this stuff.
>
> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> mark_object (arg=3271131134090376052) at alloc.c:6297
> 6297 if (STRING_MARKED_P (ptr))
> (gdb) bt
> #0 mark_object (arg=3271131134090376052) at alloc.c:6297
> #1 0x00000000005c2fe5 in mark_interval (i=0x2d65646f6d2d7370, dummy=0) at
> alloc.c:1532
This crash is in a different place in GC, but note how the value of
the argument i passed to mark_interval, 0x2d65646f6d2d7370, is again
ASCII text ("ps-mode-"). What's curiouser, GC is marking
buffer_defaults:
> #7536 0x00000000005c9609 in mark_vectorlike (ptr=0xc56d50 <buffer_defaults>)
> at alloc.c:6038
^^^^^^^^^^^^^^^
> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> mark_object (arg=10997052170605) at alloc.c:6315
> 6315 if (VECTOR_MARKED_P (ptr))
> (gdb) bt
> #0 mark_object (arg=10997052170605) at alloc.c:6315
> #1 0x00000000005c2fe5 in mark_interval (i=0xa0073636168, dummy=0) at
> alloc.c:1532
This is very similar to the above, with the text now being "hacs",
terminated by a null byte. Also, we are marking objects on the stack
in this case:
> #6 0x00000000005c7540 in mark_maybe_object (obj=66162019) at alloc.c:4743
> #7 0x00000000005c78cc in mark_memory (start=0x7fffffff89f8,
> end=0x7fffffffe758) at alloc.c:4895
> #8 0x00000000005c7900 in mark_stack (end=0x7fffffff89f8) at alloc.c:5038
> #9 0x00000000005c8e0d in garbage_collect_1 (end=0x7fffffff89f8) at
> alloc.c:5756
> #10 0x00000000005c947d in Fgarbage_collect () at alloc.c:5979
The Lisp backtraces are very different in each case, which I think
indicates the problem happens in some code entirely unrelated to the
code that crashes. It just triggers GC.
Please try lowering gc-cons-threshold, perhaps that would make the
crashes closer to the problematic code.
- bug#24764: 25.1.50; Another crash in automatic gc, (continued)
bug#24764: 25.1.50; Another crash in automatic gc, npostavs, 2016/10/22