Subject: Re: bug#41755: feature/native-comp (master?): temacs crash in GC during mark phase

From: Nicolas Bértolo <[email-masked]>
Date: Mon, 8 Jun 2020 00:39:34 -0300

I think I found the bug. Summary: A heap-based cons points to a
stack-based string. The bug was introduced by:

e38678b268c * Reduce the number of files probed when finding a lisp file.

The function load_charset_map_from_file () creates two AUTO_STRINGs for the
suffixes it needs. It puts this into a stack-based cons that it passes as the
"suffixes" argument of openp ().

This function then constructs the list of "extended suffixes" that associates
each suffix with the directory that needs to be inserted in the middle of the
path, if any. This list is allocated in the heap.

When the GC kicks in, the lists are still lying around in memory but the
stack-based strings don't exist anymore.

The attached patch fixes this case. There may be similar cases in other parts of
the code. I'll take a look.

Nico.

El dom., 7 jun. 2020 a las 20:09, Nicolas Bértolo
(<[email-masked]>) escribió:
>
> > But you still have last_marked in your build, right? That would be a
> > good starting point to find out which object was marked and what was
> > actually on the stack there...
>
> Yes, I'll take a look there. BTW, adding
>
> #pragma GCC optimize ("-O0")
>
> to the top of alloc.c does not prevent it from crashing, so debugging could be
> easier.
>
> > Is it always a symbol that's found on the stack by mark_maybe_*, though?
>
> No, in this case it is a cons.
>
> 0x0000000400115a1a in cons_marked_p (c=0xfffffffc00, c@entry=0xbf07b0)
> at alloc.c:3899
> 3899      return pdumper_object_p (c)
> (gdb) bt
> #0  0x0000000400115a1a in cons_marked_p (c=0xfffffffc00,
> c@entry=0xbf07b0) at alloc.c:3899
> #1  0x000000040011a567 in mark_object (arg=XIL(0xbf0890)) at alloc.c:6775
> #2  0x00000004001125d9 in mark_interval_tree_1 (i=0x464a9b3,
> dummy=0x0) at alloc.c:1468
> #3  0x000000040018fde4 in traverse_intervals_noorder
> (tree=tree@entry=0x464a9b3, function=function@entry=0x4001125b0
> <mark_interval_tree_1>, arg=arg@entry=0x0) at intervals.c:234
> #4  0x0000000400112619 in mark_interval_tree (i=0x464a9b3) at alloc.c:1477
> #5  0x000000040011a2d4 in mark_object (arg=XIL(0x454c0b0)) at alloc.c:6629
> #6  0x000000040011a5b2 in mark_object (arg=XIL(0x40061cf60),
> arg@entry=XIL(0x4d14553)) at alloc.c:6786
> #7  0x00000004001171dd in mark_maybe_pointer (p=p@entry=0x4d14553) at
> alloc.c:4804
> #8  0x0000000400117253 in mark_memory (start=0xbf0b30,
> start@entry=0xbff990, end=0xbff990, end@entry=0xbf0b30) at
> alloc.c:4854
> #9  0x00000004001172b0 in mark_stack (bottom=0xbff990 "",
> end=end@entry=0xbf0b30 "0\f\277") at alloc.c:5073
> #10 0x00000004001a0a71 in mark_one_thread (thread=0x400559500
> <main_thread>) at thread.c:630
> #11 mark_threads_callback (ignore=ignore@entry=0x0) at thread.c:661
> #12 0x00000004001172fe in flush_stack_call_func1
> (func=func@entry=0x4001a0a30 <mark_threads_callback>,
> arg=arg@entry=0x0) at alloc.c:5114
> #13 0x00000004001a1c9c in flush_stack_call_func (arg=0x0,
> func=0x4001a0a30 <mark_threads_callback>) at lisp.h:3825
> #14 mark_threads () at thread.c:668
> #15 0x0000000000000000 in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)