GNU bug report logs -
#58334
29.0.50; ASAN heap use after free in gui_produce_glyphs
Previous Next
Full log
View this message in rfc822 format
Po Lu <luangruo <at> yahoo.com> writes:
> Gerd Möllmann <gerd.moellmann <at> 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.
This bug report was last modified 2 years and 311 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.