Closed Bug 234911 Opened 21 years ago Closed 21 years ago

Xft: recent string change broke MathML support 'mysteriously'

Categories

(Core Graveyard :: GFX: Gtk, defect)

All
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 234908

People

(Reporter: jshin1987, Assigned: jshin1987)

Details

(Keywords: regression)

After updating my tree to the CVS trunk, I found my Xft build crashed in nsFontMetricsXft.cpp because 'null' pointer is passed to GetConverter() in the following code: http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsFontMetricsXft.cpp#2774 nsXPIDLCString encoding; ..... 2774 if (NS_SUCCEEDED(GetEncoding(family, getter_Copies(encoding), 2775 fontType, ftEncoding)) && 2776 NS_SUCCEEDED(GetConverter(encoding.get(), getter_AddRefs(converter)))) { I double-checked that |GetEncoding| returns NS_OK only when encoding is set to a non-null value [1]. Mysteriously, however, encoding.get() is null. According to gdb, 'mData' and 'mLength' members of |encoding| are "" and 0, respecitvely. How to reproduce: 1. Install MathML fonts for Xft builds (see http://www.mozilla.org/projects/mathml) 2. Launch a mozilla and try to view one of MathML pages [1] http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsFontMetricsXft.cpp#2689 2689 *aEncoding = ToNewCString(encoding); 2690 if (PR_LOG_TEST(gXftFontLoad, PR_LOG_DEBUG)) { 2691 printf("\t\tc> it's %s and encoding is %s\n", 2692 aType==eFontTypeCustom ? "narrow" : "wide", *aEncoding); Before Mozilla crashes, it prints out 'encoding' correctly.
this looks like a duplicate of bug 234908, which has a full stack. *** This bug has been marked as a duplicate of 234908 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.