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

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Date: Tue, 04 Oct 2022 16:33:45 +0200
>> 
>> 0x00011f90d0a1 is located 1953 bytes inside of 8184-byte region [0x00011f90c900,0x00011f90e8f8)
>> freed by thread T0 here:
>>     #0 0x103332de4 in wrap_free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3ede4)
>>     #1 0x100985df8 in rpl_free free.c:48
>>     #2 0x1005b6e7c in lisp_free alloc.c:1038
>
> Any idea how is the above related to the other two backtraces?  Why
> don't I see 'main' at the top of the backtrace here?  Can the
> sanitizer be asked to produce more than 30 backtrace frames?

The three backtraces are printed by the ASAN lib, with or without LLDB.

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.