GNU bug report logs - #77478
Fixes a crash in the Haiku font driver for daemon mode

Previous Next

Full log

Message #13 received at 77478 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Kyle Ambroff-Kao" <kyle <at> ambroffkao.com>,
 Po Lu <luangruo <at> yahoo.com>
Cc: 77478 <at> debbugs.gnu.org
Subject: Re: bug#77478: Details
Date: Sat, 12 Apr 2025 14:35:17 +0300

> Date: Thu, 03 Apr 2025 07:10:53 +0000
> From: "Kyle Ambroff-Kao" <kyle <at> ambroffkao.com>
> 
> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.