Closed Bug 397007 Opened 17 years ago Closed 17 years ago

"ASSERTION: no element to return" and memory corruption with :before, -moz-column

Categories

(Core :: Layout, defect)

defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla1.9beta1

People

(Reporter: jruderman, Assigned: roc)

References

Details

(Keywords: assertion, crash, testcase, Whiteboard: [sg:critical])

Attachments

(3 files, 1 obsolete file)

Loading the testcase triggers two assertions and corrupts random memory, often leading to a crash later. ###!!! 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
Flags: blocking1.9?
Whiteboard: [sg:critical]
I'm also seeing (on Linux): ###!!! ASSERTION: ResolveBidi called on non-first continuation: '!GetPrevInFlow()', file nsBlockFrame.cpp, line 6627 The crash is caused by setting a bit in arbitrary memory when |line| is an overflow line and |mLines| is empty: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/generic/nsBlockFrame.cpp&rev=3.866&root=/cvsroot&mark=5225-5226#5197
Assignee: nobody → mats.palmgren
OS: Mac OS X → All
Hardware: PC → All
Attached patch Patch rev. 1 (obsolete) — Splinter Review
* fix the assertion in comment 1. * fix the crash. (I'm guessing we don't need to set this bit in case the frame is in an overflow line.) * remove an unused variable
Attachment #281822 - Flags: superreview?(roc)
Attachment #281822 - Flags: review?(roc)
#ifdef IBMBIDI - ResolveBidi(); + if (!GetPrevInFlow()) + ResolveBidi(); #endif // IBMBIDI This is not the correct fix for this. Simon is working on a better fix in bug 394805. + if (!searchingOverflowList && line != mLines.front()) { We should still set the bit when the frame is an overflow line. We just need to check against the right first-line.
Ok, how about the case when it's the first overflow line - do we want to set the bit on the last line (if any) in mLines in that case?
Yes, actually. Good call.
Attached patch patch rev. 2Splinter Review
This crash is annoying me, so here's my stab at a patch.
Assignee: mats.palmgren → roc
Attachment #281822 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #282242 - Flags: superreview?(mats.palmgren)
Attachment #282242 - Flags: review?(mats.palmgren)
Attachment #281822 - Flags: superreview?(roc)
Attachment #281822 - Flags: review?(roc)
I need review here, Mats
Blocks: 376419
Flags: blocking1.9? → blocking1.9+
Comment on attachment 282242 [details] [diff] [review] patch rev. 2 Looks good so far, but you forgot the case in comment 4.
Attachment #282242 - Flags: superreview?(mats.palmgren)
Attachment #282242 - Flags: superreview-
Attachment #282242 - Flags: review?(mats.palmgren)
Attachment #282242 - Flags: review-
Attached patch Patch rev. 3Splinter Review
Your patch + an added else-block for the first overflow line case.
Attachment #283874 - Flags: superreview?(roc)
Attachment #283874 - Flags: review?(roc)
Attachment #283874 - Flags: superreview?(roc)
Attachment #283874 - Flags: superreview+
Attachment #283874 - Flags: review?(roc)
Attachment #283874 - Flags: review+
mozilla/layout/generic/nsBlockFrame.cpp 3.874 mozilla/layout/generic/nsBlockFrame.h 3.252 -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M9
Blocks: 398821
v. Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007110610 Minefield/3.0a9pre
Status: RESOLVED → VERIFIED
The testcase doesn't trigger any assertions or crashes on branch.
Group: security
Flags: wanted1.8.1.x-
Crashtest checked in.
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: