Subject: bug#76121: 31.0.50; crash in uniscribe_close

From: Cecilio Pardo <[email-masked]>
Date: Mon, 3 Mar 2025 18:41:58 +0100

On 01/03/2025 21:28, Pip Cet wrote:

> Just a heads-up: if uniscribe would benefit from a general mechanism to
> avoid calling the font_close method twice, it may well be worth doing
> it; the other font backends have been fixed to make font_close
> idempotent, but people are unlikely to stop writing font backends
> anytime soon :-)
> 
> Thanks for working on this!  If there's a uniscribe-specific fix that
> works, feel free to disregard this email.

The fix is simple, just setting dwrite_cache = NULL, as you already 
worked out.

 From what I see, w32font_close is already idempotent, as it tests for a 
non-null hfont.

Thanks, and my apologies for not attending to this before.

From 6c4c7e606b57bf3b10c4a2dde81e605c593edd11 Mon Sep 17 00:00:00 2001
From: Cecilio Pardo <[email-masked]>
Date: Mon, 3 Mar 2025 18:34:03 +0100
Subject: [PATCH] ; Fix bug on w32 uniscribe_close

* src/w32uniscribe.c (uniscribe_close): Set dwrite_cache member to NULL.
---
 src/w32uniscribe.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/w32uniscribe.c b/src/w32uniscribe.c
index 9986c9dc2f9..451dbabf9ff 100644
--- a/src/w32uniscribe.c
+++ b/src/w32uniscribe.c
@@ -204,6 +204,8 @@ uniscribe_close (struct font *font)
 
 #ifdef HAVE_HARFBUZZ
   w32_dwrite_free_cached_face (uniscribe_font->dwrite_cache);
+  uniscribe_font->dwrite_cache = NULL;
+
   if (uniscribe_font->w32_font.font.driver == &harfbuzz_font_driver
       && uniscribe_font->cache)
     hb_font_destroy ((hb_font_t *) uniscribe_font->cache);
-- 
2.35.1.windows.2