bug#58334: 29.0.50; ASAN heap use after free in gui_produce_glyphs

[Gerd Möllmann]

Po Lu <luangruo@yahoo.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>>     #0 0x1033f2ca8 in wrap_malloc+0x94 
>> (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x3eca8)
>>     #1 0x1005af4f4 in lmalloc alloc.c:1361
>>     #2 0x1005af40c in xmalloc alloc.c:751
>>     #3 0x1003f92b4 in make_realized_face xfaces.c:4471
>>     #4 0x1003f5c00 in realize_gui_face xfaces.c:6023
>>     #5 0x1003e4000 in realize_face xfaces.c:5954
>
> [...]
>
>>     #14 0x1005592d8 in Fvertical_motion indent.c:2241
>
> I'm pretty sure the right fix is to block input around realize_face and
> Fvertical_motion, since that code is clearly not reentrant.

If we can find one, I would prefer a broader solution, even if it is a
bit heavy-handed.  I'm a bit afraid of finding these problems piecemeal,
and it's getting a bit tiresome, but that's just me - why do I run with
ASAN...

>
>> The problem here, it seems to me, is that the redisplay done in
>> -[EmacsView layoutSublayersOfLayer:] nsterm.m:8675, frees realized faces
>> at a moment that the code doesn't cannot expect.
>
> Also, how come layoutSublayersOfLayer is called so often?  AFAIU it's
> only there to coax the system into actually resizing Emacs while the
> system blocks the input loop from returning control to Emacs, which
> should only happen during drag-to-resize.

I don't know.  Does it help if I describe what I did?

The backtrace I showed was from starting Emacs with my init file.  It
was busy with restoring desktop, I think, and at the point where frame
size and poisitino was restored (just a guess), it crashed.

Today, I got basically the same crash modulo Lisp frames in the
backtrace when finding a file in another frame.