There may be a race condition otherwise between release_gdi_font and find_cached_gdi_font, leading to invalid memory access:
One thread calling release_gdi_font may decrement refcount to 0, then try to enter font_lock. At the same time, another thread may be calling find_cached_gdi_font through select_font, holding the font_lock.
This second thread would find refcount set to 0, and then try to remove unused_entry from its list, although it hasn't been added yet to the unused list.
Another possible way to fix this would be to hold the font_lock before decrementing refcount, but that may not be as efficient.
Signed-off-by: Rémi Bernon rbernon@codeweavers.com --- dlls/win32u/font.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/dlls/win32u/font.c b/dlls/win32u/font.c index 1ac48e67d65..c9c9e8ab3b0 100644 --- a/dlls/win32u/font.c +++ b/dlls/win32u/font.c @@ -1994,6 +1994,7 @@ static struct gdi_font *alloc_gdi_font( const WCHAR *file, void *data_ptr, SIZE_ font->matrix.eM11 = font->matrix.eM22 = 1.0; font->scale_y = 1; font->kern_count = -1; + list_init( &font->unused_entry ); list_init( &font->child_fonts );
if (file)