Closed Bug 279032 Opened 18 years ago Closed 14 years ago

Crash when i try view a page with font Code128 [@ nsFontMetricsXft::CacheFontMetrics]


(Core Graveyard :: GFX: Gtk, defect)

Not set


(Not tracked)



(Reporter: yourpadremb, Assigned: karlt)


(Depends on 1 open bug, )


(Keywords: crash)

Crash Data


(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020 Firefox/0.10.1

* Crash when i try view a page with font Code128. Example

* You can download font from

* Only crash using Linux (Slackware and FC3). Windows 98, XP work fine.

* Konqueror 3.3 work fine

* I make a web-app like the sample for print credentials (use css) and crash too

Reproducible: Always

Steps to Reproduce:
1. Open with font Code128 instaled
2. Crash
Actual Results:  

Expected Results:  
Show text with font Code128
WFM, Mozilla 2005-01-17-05 trunk Linux.

Miguel, does the latest build of Firefox or Mozilla also crash?
*** Bug 279111 has been marked as a duplicate of this bug. ***
Crash too with

In aplicacin Web that I made use the type of single Code128 when printing.  
 - Print Direct work fine
 - Print Preview crah 
If it control to print if it comes out but previsualizacon crash

If run from command line say:

./ line 131: 10722 Exception of floating comma   "$prog" ${1+"$@"}

Español (Spanish)
./ line 131: 10722 Excepción de coma flotante   "$prog" ${1+"$@"}

You can see for a
sample from my web-app (remember you need have instaled font Code128Win)

This sample work fine in screen but crash on print preview
please install talkback and crash your talkback enabled build. then run talkback
and copy the incident id to this bug.
Assignee: general → blizzard
Component: General → GFX: Gtk
Product: Mozilla Application Suite → Core
QA Contact: general → ian
Version: unspecified → Trunk
Using Mozilla 1.8a5 - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5)
Gecko/20041116 - on slackware 10
Netscape Quality Feedback Agent incident id= TB3201293H
Using mozilla-suite (BUILD 2005022205) view page show in print preview
work fine (no crash) but printing no print with Font Code128

I think now what is problem with XFT and freetype?
how know what system use? XFT? or freetype2? 
about:buildconfig not say
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Closed: 17 years ago
Resolution: --- → EXPIRED
Still bug. see url

I use Slackware 10.2 
Resolution: EXPIRED → ---
reporter: could you use a talkback build again and get the talkback id again and
post it here again. and if no one gets the incident pulled in 24 hours, email
gerv complaining to him.
I can reproduce the crash in a debug build after installing the fonts.
It's a division by zero:

Program received signal SIGFPE, Arithmetic exception.
(gdb) bt
#0  0x41dd6ca7 in nsFontMetricsXft::CacheFontMetrics() (this=0x879fc50) at
#1  0x41dd6b65 in nsFontMetricsXft::RealizeFont() (this=0x879fc50) at
#2  0x41dd668d in nsFontMetricsXft::Init(nsFont const&, nsIAtom*,
nsIDeviceContext*) (this=0x879fc50, aFont=@0x88ce764, aLangGroup=0x82b7a08,
    aContext=0x8124200) at nsFontMetricsXft.cpp:445
#3  0x40c26f10 in nsFontCache::GetMetricsFor(nsFont const&, nsIAtom*,
nsIFontMetrics*&) (this=0x88952c0, aFont=@0x88ce764, aLangGroup=0x82b7a08,
    aMetrics=@0xbfffaa70) at nsDeviceContext.cpp:631
#4  0x40c26392 in DeviceContextImpl::GetMetricsFor(nsFont const&, nsIAtom*,
nsIFontMetrics*&) (this=0x8875748, aFont=@0x88ce764,
    aLangGroup=0x82b7a08, aMetrics=@0xbfffaa70) at nsDeviceContext.cpp:320
#5  0x41dd296c in nsRenderingContextGTK::SetFont(nsFont const&, nsIAtom*)
(this=0x887bd50, aFont=@0x88ce764, aLangGroup=0x82b7a08)
    at nsRenderingContextGTK.cpp:700
#6  0x414f6bdc in SetFontFromStyle(nsIRenderingContext*, nsStyleContext*)
(aRC=0x887bd50, aSC=0x41de9148) at nsFrame.cpp:442
#7  0x41557c4d in TextStyle (this=0xbfffacc0, aPresContext=0x8786af0,
aRenderingContext=@0x887bd50, sc=0x88ce460) at nsTextFrame.cpp:458
#8  0x415614ea in nsTextFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&,
nsHTMLReflowState const&, unsigned&) (this=0x88ce4b0,

(gdb)  fr 0
#0  0x41dd6ca7 in nsFontMetricsXft::CacheFontMetrics() (this=0x879fc50) at
843         mEmAscent = nscoord(mMaxAscent * mEmHeight / lineHeight);
(gdb) p lineHeight
$2 = 0
(gdb) p *this
$3 = {<nsIFontMetricsGTK> = {<nsIFontMetrics> = {<nsISupports> =
{_vptr.nsISupports = 0x41de9528}, mFont = {
        name = {<nsSubstring> = {<nsAString_internal> = {mVTable = 0x4014c188,
mData = 0x887e3c8, mLength = 22,
              mFlags = 5}, <No data fields>}, <No data fields>}, style = 0,
systemFont = 0, variant = 0 '\0', familyNameQuirks = 0 '\0',
        weight = 400, decorations = 0 '\0', size = 280, sizeAdjust = 0}}, <No
data fields>}, mRefCnt = {mValue = 1}, _mOwningThread = {
    mThread = 0x8074c00}, mFontList = {<nsVoidArray> = {_vptr.nsVoidArray =
0x40148ac8, mImpl = 0x887bde0}, <No data fields>},
  mFontIsGeneric = {<nsVoidArray> = {_vptr.nsVoidArray = 0x40148b08, mImpl =
    mAutoBuf = "\b\000\000\000\002\000\000\000\000\000\000\000\001", '\0'
<repeats 26 times>}, mDeviceContext = 0x8875748, mLangGroup = {
    mRawPtr = 0x82b7a08}, mGenericFont = 0x82b8d98, mPixelSize = 18.6666679,
  mDefaultFont = {<nsFixedCString> = {<nsCString> = {<nsCSubstring> =
{<nsACString_internal> = {mVTable = 0x4014c108, mData = 0x879fcdc "",
            mLength = 0, mFlags = 65553}, <No data fields>}, <No data fields>},
mFixedCapacity = 63, mFixedBuf = 0x879fcdc ""},
    mStorage = '\0' <repeats 63 times>}, mLoadedFonts = {_vptr.nsVoidArray =
0x40148b28, mImpl = 0x8880410}, mWesternFont = 0x8881e88,
  mPattern = 0x887dcb0, mMatchType = eBestMatch, mMiniFont = 0x0, mMiniFontWidth
= 0, mMiniFontHeight = 0, mMiniFontPadding = 0,
  mMiniFontYOffset = 0, mMiniFontAscent = 0, mMiniFontDescent = 0, mXHeight = 0,
mSuperscriptOffset = 0, mSubscriptOffset = 0,
  mStrikeoutOffset = 0, mStrikeoutSize = 0, mUnderlineOffset = 0, mUnderlineSize
= 0, mMaxHeight = 0, mLeading = 0, mEmHeight = 270,
  mEmAscent = 0, mEmDescent = 0, mMaxAscent = 0, mMaxDescent = 0, mMaxAdvance =
0, mSpaceWidth = 0, mAveCharWidth = 0}
(gdb) p *xftFont
$4 = {ascent = 0, descent = 0, height = 2, max_advance_width = 19, charset =
0x83c3310, pattern = 0x887b2b0}
Ever confirmed: true
Keywords: crash
Attached patch wipSplinter Review
This fixes the URL (I see a bar code).
I'm not sure if this is a good thing though, maybe leaving the line-height etc
as zero would be more correct...
FWIW, Opera8 on Linux renders a bar code.
David, roc, what should we do when the font claims a line-height of 0?
my guess is that if lineHeight is zero then all height metrics should be zero.
We should warn if any from the font are nonzero and set them all to zero.
Using lastes-trunk it still crash the url
it not apply the path yet?
Once the patch is checked in, the bug will be resolved fixed.  That hasn't happened yet, because it's not clear that this patch is the right one.
Blocks: 379037
Summary: Crash when i try view a page with font Code128 → Crash when i try view a page with font Code128 [@ nsFontMetricsXft::CacheFontMetrics]
If it does any matter now (it doesn't seem to happen on Trunk), the crash has also been spotted with a font called “Topiary Initials”: TB35680274M with and TB35680527Q with todays Crash on selection of the font in the font list.
Using last trunk (mozilla 3) work fine. not more crash. 

But still another problem: it text don't have correct position, 2mm above
i think this it another thread.
Duplicate of this bug: 379037
I'm guessing trunk is not crashing now because it is using floating point arithmetic for the division instead of integers.

It wouldn't surprise me if there are some OpenType fonts that have good metrics in the OS/2 table but poor (zero) metrics in the HHEA table, which is used on Mac and by Freetype (and thus Xft and cairo).

We could fallback to usWinAscent/usWinDescent metrics if the HHEA ascent is zero, or we could use the maximum of the HHEA values and the sTypoAscender/Descender.
Depends on: 402473
Assignee: blizzard → mozbugz
Severity: critical → normal
Depends on: 403618
(In reply to comment #21)
> But still another problem: it text don't have correct position, 2mm above
> i think this it another thread.

Changes in bug 385263 now cause fallback to metrics in the OS/2 table if the metrics in the HHEA table are poor, so this should now be fixed (in nightly builds).
Closed: 17 years ago14 years ago
Depends on: 385263
No longer depends on: 403618
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1b1
Product: Core → Core Graveyard
Crash Signature: [@ nsFontMetricsXft::CacheFontMetrics]
You need to log in before you can comment on or make changes to this bug.