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

[Eli Zaretskii <eliz@gnu.org>]

On June 8, 2020 6:39:34 AM GMT+03:00, "Nicolas Bértolo" <nicolasbertolo@gmail.com> wrote:
> 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
> (<nicolasbertolo@gmail.com>) 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?)

Thanks, but are you sure the fix should be in load_charset_map_from_file and not in the new code added to openp in the offending commit?  Why does the additional code in openp need to cons its list off the heap?

IOW, it sounds like those additions now made openp unsafe for callers who manipulate stack-based Lisp objects.  The old openp was AFAIK careful enough not to impose any constraints like that on its callers.