GNU bug report logs - #76121
31.0.50; crash in uniscribe_close

Previous Next

Full log

View this message in rfc822 format

From: Richard Copley <rcopley <at> gmail.com>
To: 76121 <at> debbugs.gnu.org, Cecilio Pardo <cpardo <at> imayhem.com>
Cc: Pip Cet <pipcet <at> protonmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#76121: 31.0.50; crash in uniscribe_close
Date: Sat, 8 Feb 2025 09:47:58 +0000

Two replies were inadvertently sent off-list:

> >> [Pip Cet:]
> >> I guess we can remove the fprintf statements (I'm not even sure those
> >> work on Windows, but I've learned the hard way not to use other printing
> >> functions from GC), and keep just the return...
> >
> > [Richard Copley]:
> > I think we still want to call 'w32font_close' from 'uniscribe_close'
> > if the font never had a non-null 'uniscribe_font->cache'. Maybe that
> > never happens, but if 'uniscribe_close' is ever called right after
> > 'uniscribe_open' (which see), it would.
>
> [Pip Cet:]
> Thanks! You're right!
>
> haikufont_close seems similarly unsafe (but it has the
> font_data_structures_may_be_ill_formed hack so it probably simply leaks
> memory rather than crashing).  And I haven't checked the android case
> which has extra code in alloc.c.
>
> I still think we should fix this properly by ensuring the close_font
> method is called at most once on each font object (setting font->driver
> to NULL after calling it), but I seem to recall suggesting this before a
> while ago, so I guess we decided against it.

Previous Next

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