bug#58042: 29.0.50; ASAN use-after-free in re_match_2_internal

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: 58042@debbugs.gnu.org
> Date: Wed, 05 Oct 2022 06:37:58 +0200
> 
> >From top to bottom we're going into the past
> 
> 1. Present = Where the problem was found with the pointer
> 2. Past = where the memory block was freed that the pointer is in.
> 3. Pre-Past = where block was allocated that is freed in (2)
> 
> I don't know why the ASAN output in (1) stops after 30 frames.  And I
> don't know if the 30 can be changed.  But 30 for (2) and (3) seems
> reasonable to me.  After all, this means 2 * 30 pointers most be
> recorded per allocated memory block, and that's a quite noticeable
> overhead, performance-wise.  30 looks like a heuristic.  More make
> programs slower, less is less helpful.
> 
> When running under LLDB, we stop at (1), and can see the full callstack,
> if we want, starting in the ASAN lib where it signals SIGABRT, and going
> up to main etc.

Then I guess we will have to wait until LLDB folks get their act
together and fix LLDB to not crash before it provides the information
to us?  Or is it possible for you to downgrade to the previous,
working version of LLDB?

The question that we should try answering is this: what variable holds
the C pointer to the data of a Lisp string that is being relocated
and/or compacted by GC between the time the C pointer is assigned and
the time its value is dereferenced?  And I don't see how to answer
that question without understanding how redisplay was called in the
middle of what seems to be loading of a Lisp package, because none of
the items 1 and 3 show anything that could call redisplay.