GNU bug report logs -
#77478
Fixes a crash in the Haiku font driver for daemon mode
Previous Next
Full log
Message #16 received at 77478 <at> debbugs.gnu.org (full text, mbox):
Ping! Po Lu, any suggestions or comments?
> Cc: 77478 <at> debbugs.gnu.org
> Date: Sat, 12 Apr 2025 14:35:17 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > 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?
>
>
>
>
This bug report was last modified 25 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.