Subject: Re: bug#77478: Fixes a crash in the Haiku font driver for daemon mode

From: Po Lu <[email-masked]>
Date: Sat, 10 May 2025 21:10:59 +0800

Eli Zaretskii <[email-masked]> writes:

> Ping! Ping!  Po Lu, please respond.
>
>> Cc: [email-masked], [email-masked]
>> Date: Sat, 26 Apr 2025 14:34:52 +0300
>> From: Eli Zaretskii <[email-masked]>
>> 
>> Ping!  Po Lu, any suggestions or comments?
>> 
>> > Cc: [email-masked]
>> > Date: Sat, 12 Apr 2025 14:35:17 +0300
>> > From: Eli Zaretskii <[email-masked]>
>> > 
>> > > Date: Thu, 03 Apr 2025 07:10:53 +0000
>> > > From: "Kyle Ambroff-Kao" <[email-masked]>
>> > > 
>> > > This fixes double-free bug in Emacs daemon mode on Haiku. To reproduce:
>> > > 
>> > > 1. Start emacs with "emacs --daemon"
>> > > 2. Create a new frame with "emacsclient -c" and then close it.
>> > > 3. Create a new frame with "emacsclient -c"
>> > > 
>> > > Step 3 will cause the Emacs daemon to crash.
>> > > 
>> > >   KERN: debug_server: Thread 3616 entered the debugger: Debugger call:
>> > >   `tried to free 0xb960bc9fd0 which points at page 232 which is not an
>> > >   allocation first page'
>> > > 
>> > > The backtrace from Emacs:
>> > >    heap_free(void*) + 0x35 
>> > >    BFont_close + 0x4d 
>> > >    haikufont_close(font*) + 0x29 (/Code/emacs/src/haikufont.c:893)
>> > >    sweep_vectors(void) + 0x1af (/Code/emacs/src/alloc.c:3242)
>> > >    garbage_collect(void) + 0x7b3 (/Code/emacs/src/alloc.c:7247)
>> > >    Ffuncall(ptrdiff_t, Lisp_Object*) + 0x194 (/Code/emacs/src/eval.c:3084)
>> > >    internal_condition_case_n(*, ptrdiff_t, Lisp_Object*, Lisp_Object, *)
>> > >    + 0x6c (/Code/emacs/src/eval.c:1699)
>> > >    safe_funcall(ptrdiff_t, Lisp_Object*) + 0x50 (/Code/emacs/src/eval.c:3114)
>> > >    map_keymap_canonical(Lisp_Object,map_keymap_function_t,Lisp_Object,void*)
>> > >    + 0x2b (/Code/emacs/src/keymap.c:608)
>> > >    ...
>> > > 
>> > > It appears that the BFont has already been closed. I think that the
>> > > driver is holding on to the pointer to the freed BFont
>> > > (into->be_font). This patch addresses this by setting be_font to NULL so
>> > > that this pointer will not be freed again.
>> > > 
>> > > The same thing applies to info->metrics and info->glyphs, since just
>> > > making this change to be_font wasn't enough to avoid crashes.
>> > > 
>> > > With this patch I can open and close as many frames as I want without
>> > > crashing.
>> > > 
>> > > I don't totally understand the interactions here, and I see there are
>> > > similar bugs in other font drivers with different workarounds. For
>> > > example, in Bug#16069 which I found from xfont.c:xfont_close, it seems
>> > > like there is an attempt to just not free the fonts when GC is invoked.
>> > > 
>> > > I think the solution in this patch seems a little simpler, but possibly
>> > > means that the fonts are initialized every time the frame count goes
>> > > from 0 to 1 or more instead of just once for the life of the daemon.
>> > 
>> > Po Lu, any suggestions or comments?

Sorry for the very belated response.  I'll get around to reading these
bug reports in roughly a week--but superficially the OP's analysis
appears correct.