Closed Bug 390052 Opened 13 years ago Closed 13 years ago

crash/freeze on viewing page


(Core :: Layout: Text and Fonts, defect, critical)

Not set





(Reporter: stefanvalouch, Assigned: roc)



(Keywords: assertion, crash, hang)


(2 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6) Gecko/20070629 GranParadiso/3.0a6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6) Gecko/20070629 GranParadiso/3.0a6

updating phpBB3RC3 to RC4, they introduced a new file. viewing it with phpBB3s own diff-viewer or through viewvc crashes FF 3.0A6.

Reproducible: Always

Steps to Reproduce:
1.unzip a phpBB3RC3 from to a www-root and unzip the "german (du)" language files and pro/subsilver imagesets
2.install it through a webbrowser
3.get the [ Automatic Update Package (RC3 to RC4) ] package, unzip to board-root
4.use the updater, in step "Dateien überprüfen" click on

    [ Dateiinhalte zeigen ] 

OR (easier)
go to
Actual Results:  
freeze with 100% kernel-load, nothing on stdout/stderr

Expected Results:  
the source of the file

no problems in FF, there i see some boxes with two 2-digit hexnumbers in it (quite normal, happens everytime the char can not be displayed).

I don't know what happens during the crash/freeze, profiles don't get into trouble i think.
I don't know it is a security issue
Confirming hang.  In a debug build I get one:

###!!! ASSERTION: frame offsets overlap!: 'mappedFlow->mContentEndOffset <= frame->GetContentOffset()', file nsTextFrameThebes.cpp, line 1343

In a debugger it looks like we're constantly in font related code.
Component: General → Layout: Fonts and Text
Ever confirmed: true
Keywords: assertion, crash, hang
Product: Firefox → Core
QA Contact: general → layout.fonts-and-text
Version: unspecified → Trunk
Attached file Testcase #1
okay, problem still exists in alpha 7
i found bug 357637, and now i let firefox stay on that tab instead of killing it with sigTERM/KILL. After 3-4 minutes, the page appeared, and load went down to normal. every change to the page (selecting, copying, scrolling, resizing) needs up to 6 minutes.

It may be possible that this bug is a duplicate to bug 357637, but that bug seems to be fixed and the problem still exists here. I haven't found out yet what sort of characters make the problem in phpBB3-CVS or Testcase #1, but maybe there are some other chars than in bug 357637...
There's another page where an error occures: 
there is only a small number of those chars, so testing which one causes the probem should be easiert.
the bug-assistant of FF already reported the crashes i had today till i found out which page made the problems
Here's a somewhat-reduced version of the previous testcase (about 8k instead of 50k).

This new testcase triggers a crash, not a freeze.
I take that back -- my new testcase just *sometimes* triggers a crash.  I can generally crash within a minute from loading it and rapidly hitting reload.

I get lots of these assertions/warnings:

WARNING: Break suggested inside cluster!: file [src]/mozilla/gfx/thebes/src/gfxFont.cpp, line 771

###!!! ASSERTION: Started word in the middle of a cluster...: 'aSource->IsClusterStart(start)', file [src]/mozilla/gfx/thebes/src/gfxFont.cpp, line 1661

###!!! ASSERTION: Overran end of string: 'listPrefixLength == mSkipChars->mListLength - 1 && offsetIntoCurrentRun == currentRunLength', file [src]/mozilla/gfx/thebes/src/gfxSkipChars.cpp, line 211

###!!! ASSERTION: Invalid offset: 'aOffset <= mSkipChars->mCharCount', file /scratch/work/builds/trunk.07-08-14.09-43/mozilla/gfx/thebes/src/gfxSkipChars.cpp, line 92

Here's of the backtrace at the crash:

#0  0xb671b10b in gfxSkipCharsIterator::SetOffsets (this=0xbfd768d4, 
    aOffset=5174, aInOriginalString=1)
    at /scratch/work/builds/trunk.07-08-14.09-43/mozilla/gfx/thebes/src/gfxSkipChars.cpp:129
#1  0xb5d982dc in gfxSkipCharsIterator::AdvanceOriginal (this=0xbfd768d4, 
    aDelta=365) at ../../dist/include/thebes/gfxSkipChars.h:296
#2  0xb5d8ea7f in BuildTextRunsScanner::SetupBreakSinksForTextRun (
    this=0xbfd78e04, aTextRun=0x8ed61e0, aIsExistingTextRun=0, 
    at /scratch/work/builds/trunk.07-08-14.09-43/mozilla/layout/generic/nsTextFrameThebes.cpp:1891
#3  0xb5d8fde1 in BuildTextRunsScanner::BuildTextRunForFrames (
    this=0xbfd78e04, aTextBuffer=0x91cfc38)
    at /scratch/work/builds/trunk.07-08-14.09-43/mozilla/layout/generic/nsTextFrameThebes.cpp:1786
#4  0xb5d90587 in BuildTextRunsScanner::FlushFrames (this=0xbfd78e04, 
    at /scratch/work/builds/trunk.07-08-14.09-43/mozilla/layout/generic/nsTextFrameThebes.cpp:1252
#5  0xb5d9138c in BuildTextRuns (aRC=0x8cee358, aForFrame=0x8ad6170, 
    aLineContainer=0x8ac8e8c, aForFrameLine=0xbfd7983c)
    at /scratch/work/builds/trunk.07-08-14.09-43/mozilla/layout/generic/nsTextFrameThebes.cpp:1211
#6  0xb5d91468 in nsTextFrame::EnsureTextRun (this=0x8ad6170, aRC=0x8cee358, 
    aLineContainer=0x8ac8e8c, aLine=0xbfd7983c, aFlowEndInTextRun=0xbfd79428)
    at /scratch/work/builds/trunk.07-08-14.09-43/mozilla/layout/generic/nsTextFrameThebes.cpp:1968
#7  0xb5d92286 in nsTextFrame::Reflow (this=0x8ad6170, 
    aPresContext=0x8b58870, aMetrics=@0xbfd79588, aReflowState=@0xbfd794dc, 
    at /scratch/work/builds/trunk.07-08-14.09-43/mozilla/layout/generic/nsTextFrameThebes.cpp:5284

We get the crash because the array-index mListPrefixLength is huge (147784192 in my case) in this line within gfxSkipChars.cpp:
 129    PRInt32 currentRunLength = mSkipChars->mList[mListPrefixLength];

Looks like we may have gotten into some uninitialized memory.
Looks like the crash in the reduced test case is at the same point as in bug 390417 / bug 386584.
Crash and assertions seem to be fixed by patch for Bug 385270.  Hang remains, though.
Assignee: nobody → roc
The long line in the testcase is simply very long. It even hangs `links`, which doesn't do any graphics :)

My text editors (mousepad, scite) are barely able to deal with it. IE7 on Vista has a hard time with it too.

Does someone have a solution in mind?

Is it to improve the performance? Or is it to add a 'takes too long to load/render' feature like the javascript 'takes too long to run'?
We're spending all our time in font fallback on Mac --- I think this is just a pathologically slow case for font fallback. Font fallback performance could be improved.
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
Closed: 13 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 396726
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.