Closed Bug 376419 Opened 18 years ago Closed 17 years ago

Crash [@ nsLineLayout::ReflowFrame][@ nsInlineFrame::ReparentFloatsForInlineChild] with generated content and ::first-line and -moz-column

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: martijn.martijn, Assigned: roc)

References

Details

(Keywords: crash, regression, testcase)

Crash Data

Attachments

(1 file)

testcase
(deleted), text/html
Details
Attached file testcase (deleted) — 
See testcase, this crashes current Mozilla trunk build on load.
It doesn't crash in a 2007-02-06 build, but does crash in a 2007-02-07 build:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-02-06+09&maxdate=2007-02-07+07&cvsroot=%2Fcvsroot
I guess a regression from bug 177805, somehow. Not sure if that really is useful.

Talkback ID: TB30862761G
0x034a6c9e
nsLineLayout::ReflowFrame  [mozilla/layout/generic/nslinelayout.cpp, line 1045]
Summary: [columns] Crash [@ nsLineLayout::ReflowFrame] with generated content and ::first-line → Crash [@ nsLineLayout::ReflowFrame] with generated content and ::first-line and -moz-column
WFM, Mac trunk nightly.  Does it still crash for you?

Does the crash depend on the width of your browser window?  If so, you might try making a testcase that doesn't.
The testcase is still crashing, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070423 Minefield/3.0a4pre
I tried 3 different browser window sizes, it crashes in all 3 of them, so it doesn't seem to depend on the window size.

Talkback ID: TB31478740Z
nsInlineFrame::ReparentFloatsForInlineChild  [mozilla/layout/generic/nsinlineframe.cpp, line 263]
nsInlineFrame::ReflowInlineFrame  [mozilla/layout/generic/nsinlineframe.cpp, line 649]
nsInlineFrame::ReflowFrames  [mozilla/layout/generic/nsinlineframe.cpp, line 489]
nsInlineFrame::Reflow  [mozilla/layout/generic/nsinlineframe.cpp, line 408]
nsLineLayout::ReflowFrame  [mozilla/layout/generic/nslinelayout.cpp, line 889]
Summary: Crash [@ nsLineLayout::ReflowFrame] with generated content and ::first-line and -moz-column → Crash [@ nsLineLayout::ReflowFrame][@ nsInlineFrame::ReparentFloatsForInlineChild] with generated content and ::first-line and -moz-column
Still crashing, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070611 Minefield/3.0a6pre
Is this still crashing for you?  It works fine for me in a build from today.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a6pre) Gecko/20070629 Minefield/3.0a6pre ID:2007062910
I still see a crash if I load the testcase and increase the font-size three times. (I'm not getting talkback/breakpad appear, so I can't be sure it's the same crash tho)
I wonder if the crash depends on what fonts are installed?
Is this still crashing?
Yes, still crashing, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007072505 Minefield/3.0a7pre
As Steve said in comment 5, you need to increase the font-size now a bunch of times to get the crash.
Flags: blocking1.9?
I get a crash if I increase the font size three times, but the crash seems to be a text thing (bug 385270 / bug 386476) and not a -moz-column / :first-line layout thing. The crash is [@ nsTextFrameUtils::TransformText] and it is preceded by 

###!!! ASSERTION: Attempting to allocate excessively large array: 'Error', file nsTArray.cpp, line 68

I'm testing with Mac trunk debug.

Now, when I increase the font size three times, I get:

yikes! spinning on a line over 1000 times!
(abort in debug / hang in opt)

That happens now with a few other testcases related to bug 385270 as well.  Hmm.
The patch in bug 390050 fixes some more serious issues with textruns and columns.
I still see the problem in comment 10 even now that bug 390050 is fixed.
Just before the "yikes!" abort, I see a bunch of repeated assertions, including:

###!!! ASSERTION: Invalid offset: 'aOffset <= mSkipChars->mCharCount', file /Users/jruderman/trunk/mozilla/gfx/thebes/src/gfxSkipChars.cpp, line 92


Now instead of the hang and "invalid offset", I get

###!!! ASSERTION: Attempting to allocate excessively large array: 'Error', file nsTArray.cpp, line 68

and a crash like in bug 384527.
Assignee: nobody → roc
Flags: blocking1.9? → blocking1.9+
Now (still on Mac) I get:

###!!! ASSERTION: no element to return: '!empty()', file /Users/jruderman/trunk/mozilla/layout/generic/nsLineBox.h, line 1247
###!!! ASSERTION: running past end: 'mCurrent != mListLink', file /Users/jruderman/trunk/mozilla/layout/base/../generic/nsLineBox.h, line 620

like in bug 397007.  I haven't tested to see whether roc's patch in that bug helps here.
Depends on: 397007
Before bug 397007 was fixed, I see the same assertions as in last comment and
then a crash.  With bug 397007 fixed the assertions and crash is gone. On Linux.

I still see:
###!!! ASSERTION: ResolveBidi called on non-first continuation: '!GetPrevInFlow()', file nsBlockFrame.cpp, line 6670
but bug 394805 should fix that.
Flags: in-testsuite?
Whiteboard: FIXED?
Yes, the testcase loads without assertions now that 394805 is fixed.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Crash Signature: [@ nsLineLayout::ReflowFrame] [@ nsInlineFrame::ReparentFloatsForInlineChild]
Crash test:
https://hg.mozilla.org/integration/mozilla-inbound/rev/3c9de8f7331f
Crash Signature: [@ nsLineLayout::ReflowFrame] [@ nsInlineFrame::ReparentFloatsForInlineChild] → [@ nsLineLayout::ReflowFrame] [@ nsInlineFrame::ReparentFloatsForInlineChild]
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: