Sophie

Sophie

distrib > Mandriva > 2009.0 > i586 > by-pkgid > 633938929c9a915d8b94645b3b251e5a > files > 4

WindowMaker-0.92.0-19mdv2009.0.src.rpm

From bde6857c9b48fbf2ff9988351138ed4e9a6f89eb Mon Sep 17 00:00:00 2001
From: Carlos R. Mafra <crmafra@ift.unesp.br>
Date: Mon, 7 Apr 2008 10:33:22 -0300
Subject: [PATCH] WINGs/wfont.c: Avoid WMCreateFont() from returning font=NULL

WPrefs tries to use the fonts listed in the WMCreateFont() call (from WPrefs.c),

font = WMCreateFont(scr, "Lucida Sans,URW Gothic L,Times New Roman,serif"
                        ":bold:pixelsize=26:antialias=true");

and 'font' is later used without accounting the possibility of it being "NULL" in
(also from WPrefs.c)

WMSetLabelFont(WPrefs.nameL, font);
WMReleaseFont(font);

In particular, WMReleaseFont(font) will kill WPrefs ungracefully with the
following message if font="NULL":

WPrefs: wfont.c:193: WMReleaseFont: Assertion `font!=((void *)0)' failed.
Aborted

That happens because the return value of WMCreateFont() can be null, so this
patch makes WMCreateFont() never return NULL. If the font creation fails for
some reason (see below), we try to use the emergency DEFAULT_FONT and print
debugging information telling what's going on. If the use of DEFAULT_FONT
also fails, then we terminate WPrefs with exit(1) and let the user know
why exactly if failed.

This font=NULL bug happened because the font "Lucida Sans" (the first possibility
in the initial call to WMCreateFont()) "exists" in my system as a stale symbolic
link to a location which no longer exists after an upgrade from java from 1.5.0.14
to 1.5.0.15

/etc/alternatives/LucidaSansDemiBold.ttf ->
/usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/lib/fonts/LucidaSansDemiBold.ttf

So, due to this bug (elsewhere in the Mandriva update system) of not removing
this symbolic link and updating it to the new java directory, the call to
XftFontOpenName(display, scrPtr->screen, fname) with "Lucida Sans" being
the first possibility for Xft to try out ended up in 'font' being NULL, because
as far as the Xft library was concerned, "Lucida Sans" produced a positive
font match (due to it existing as a symbolic link) but in the end a NULL
result was produced due to the missing symbolic link destination. This later
exposed the bug of WMCreateFont() returning font=NULL and WPrefs.c not checking
whether font=NULL before using it. Bang!

If "Lucida Sans" was the _second_ entry to try and the first one had suceeded,
this bug would not have surfaced.

This patch makes the situation a bit more robust and prints better error messages
in case of another (unprobable) failure.

Signed-off-by: Carlos R. Mafra <crmafra@ift.unesp.br>
---
 WINGs/wfont.c |   13 ++++++++++---
 1 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/WINGs/wfont.c b/WINGs/wfont.c
index 03c6d00..0279d1c 100644
--- a/WINGs/wfont.c
+++ b/WINGs/wfont.c
@@ -159,10 +159,17 @@ WMCreateFont(WMScreen *scrPtr, char *fontName)
 
     font->font = XftFontOpenName(display, scrPtr->screen, fname);
     if (!font->font) {
-        wfree(font);
-        wfree(fname);
-        return NULL;
+	printf("Font named %s doesn't exist.\n", fname);
+	printf("Please check your system configuration.\n");
+	printf("Will try default font %s.\n", DEFAULT_FONT);
+	font->font = XftFontOpenName(display, scrPtr->screen, DEFAULT_FONT);
+	if (!font->font) {
+	    printf("Unrecoverable font error! I must die!\n");
+	    exit(1);
+	} else
+	   printf("Default font loading succeded.\n");
     }
+	 
     font->height = font->font->ascent+font->font->descent;
     font->y = font->font->ascent;
 
-- 
1.5.4.3