Closed
Bug 390052
Opened 17 years ago
Closed 17 years ago
crash/freeze on viewing page
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 396726
People
(Reporter: stefanvalouch, Assigned: roc)
References
Details
(Keywords: assertion, crash, hang)
Attachments
(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 sourceforge.net viewvc crashes FF 3.0A6. Reproducible: Always Steps to Reproduce: 1.unzip a phpBB3RC3 from http://www.phpbb.com/downloads/development.php 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 includes/utf/data/ confusables.php [ Dateiinhalte zeigen ] OR (easier) go to http://phpbb.cvs.sourceforge.net/phpbb/phpBB2/includes/utf/data/confusables.php?revision=1.3&view=markup Actual Results: freeze with 100% kernel-load, nothing on stdout/stderr Expected Results: the source of the file no problems in FF 2.0.0.4/5, 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
Comment 1•17 years ago
|
||
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.
Comment 2•17 years ago
|
||
Assignee | ||
Updated•17 years ago
|
Flags: blocking1.9?
Reporter | ||
Comment 3•17 years ago
|
||
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...
Reporter | ||
Comment 4•17 years ago
|
||
There's another page where an error occures: http://www.heise.de/newsticker/meldung/94060/from/atom10 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
Comment 5•17 years ago
|
||
Here's a somewhat-reduced version of the previous testcase (about 8k instead of 50k). This new testcase triggers a crash, not a freeze.
Comment 6•17 years ago
|
||
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, aSuppressSink=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, aFlushLineBreaks=1) 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, aStatus=@0xbfd796e4) 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.
Comment 7•17 years ago
|
||
Looks like the crash in the reduced test case is at the same point as in bug 390417 / bug 386584.
Comment 8•17 years ago
|
||
Crash and assertions seem to be fixed by patch for Bug 385270. Hang remains, though.
Assignee | ||
Updated•17 years ago
|
Assignee: nobody → roc
Comment 9•17 years ago
|
||
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'?
Assignee | ||
Comment 10•17 years ago
|
||
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?
Assignee | ||
Updated•17 years ago
|
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
Assignee | ||
Updated•17 years ago
|
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Comment 12•6 years ago
|
||
Pushed by mpalmgren@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/2743aaf261ff Add a crashtest. r=me
Updated•6 years ago
|
Flags: in-testsuite+
Comment 13•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/2743aaf261ff
You need to log in
before you can comment on or make changes to this bug.
Description
•