Closed Bug 234911 Opened 20 years ago Closed 20 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: 20 years ago
Resolution: --- → DUPLICATE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.