Closed Bug 350370 Opened 14 years ago Closed 14 years ago

[FIX] Crash [@ nsStyleContext::FindChildWithRules] with ::first-line, appending rows and table-cells, etc

Categories

(Core :: Layout, defect)

x86
All
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: martijn.martijn, Assigned: mats)

References

(Blocks 1 open bug)

Details

(5 keywords, Whiteboard: [sg:critical][baking 8/29][reflow-refactor])

Crash Data

Attachments

(3 files)

See upcoming testcase, which crashes current branch (1.8.0.x and 1.8.1) and trunk builds.
It doesn't crash Mozilla1.7.13.
This seems to have regressed between 2005-01-03 and 2005-01-04:
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=2005-01-03+11&maxdate=2005-01-04+08&cvsroot=%2Fcvsroot
Maybe a regression from bug 271422 somehow?

Talkback ID: TB22561642M
nsStyleContext::FindChildWithRules   nsStyleSet::GetContext   nsStyleSet::ReParentStyleContext   nsFrameManager::ReParentStyleContext   nsFirstLineFrame::PullOneFrame   nsLineLayout::ReflowFrame  

I have several in-between testcases, that crash in different areas, mostly in the style system. I can attach those, if wanted.
Patch coming up...
Assignee: nobody → mats.palmgren
Summary: Crash [@ nsStyleContext::FindChildWithRules] with ::first-line, appending rows and table-cells, etc → [FIX] Crash [@ nsStyleContext::FindChildWithRules] with ::first-line, appending rows and table-cells, etc
Flags: blocking1.9?
Flags: blocking1.8.1?
Flags: blocking1.8.1? → blocking1.8.1+
Attached patch Patch rev. 1Splinter Review
The problem is that we iterate past the beginning on a line iterator.
We actually have an assertion for this but still continue to execute
leading to a near certain crash on Windows (it crashes less often on
Linux for some reason).

Test results with the patch:
I ran all the testcases in the zip archive for at least 5 minutes,
up to an hour for some, on both Windows and Linux and there were
no crashes. There are plenty of nasty assertions though, especially
the table related ones looks interesting...

I wanted to have two separate assertions, the first indicates a broken
frame tree while the second could also happen for a valid frame tree.
Attachment #235697 - Flags: superreview?(bzbarsky)
Attachment #235697 - Flags: review?(bzbarsky)
sg: we're using random memory and in some cases overwrite the stack.
Flags: blocking1.8.0.7?
OS: Windows XP → All
Comment on attachment 235697 [details] [diff] [review]
Patch rev. 1

Looks ok for branches.  On trunk, I'd just as soon not touch this code -- it's completely gone on reflow branch, and changing it will just make merging the branch that much more work.
Attachment #235697 - Flags: superreview?(bzbarsky)
Attachment #235697 - Flags: superreview+
Attachment #235697 - Flags: review?(bzbarsky)
Attachment #235697 - Flags: review+
Whiteboard: [reflow-refactor]
Landing it on the trunk is fine -- these pieces are the easy ones to merge.
If dbaron's ok with it, then go ahead and land on trunk too, sure.
Landed on trunk at 2006-08-28 00:30 PDT.

-> FIXED
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
This will have to wait for 1.8.0.8
Flags: blocking1.8.0.7? → blocking1.8.0.8?
Comment on attachment 235697 [details] [diff] [review]
Patch rev. 1

approved for 1.8.0 branch, a=dveditz for drivers

We are slipping the candidate build until tomorrow. Please land this today to make 1.8.0.7
Attachment #235697 - Flags: approval1.8.0.7+
Flags: blocking1.8.0.8? → blocking1.8.0.7+
Attachment #235697 - Flags: approval1.8.1?
Whiteboard: [reflow-refactor] → [baking 8/29][reflow-refactor]
Comment on attachment 235697 [details] [diff] [review]
Patch rev. 1

we're building now, I guess this will have to be 1.8.0.8 after all.
Attachment #235697 - Flags: approval1.8.0.7+ → approval1.8.0.8?
Flags: blocking1.8.0.8+
Flags: blocking1.8.0.7-
Flags: blocking1.8.0.7+
Comment on attachment 235697 [details] [diff] [review]
Patch rev. 1

a=schrep for drivers.
Attachment #235697 - Flags: approval1.8.1? → approval1.8.1+
Landed on MOZILLA_1_8_BRANCH at 2006-08-31 09:57 PDT.
Keywords: fixed1.8.1
Restoring lost blocking flag
Flags: blocking1.8.0.8?
Flags: blocking1.8.0.8? → blocking1.8.0.8+
Comment on attachment 235697 [details] [diff] [review]
Patch rev. 1

approved for 1.8.0 branch, a=dveditz for drivers
Attachment #235697 - Flags: approval1.8.0.9? → approval1.8.0.8+
Landed on MOZILLA_1_8_0_BRANCH at 2006-10-05 16:56 PDT.
Flags: blocking1.9?
Keywords: fixed1.8.0.8
Whiteboard: [baking 8/29][reflow-refactor] → [sg:critical][baking 8/29][reflow-refactor]
v.fixed on 1.8.0 branch with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.8pre) Gecko/20061020 Firefox/1.5.0.8pre, no crash.
Group: security
Comment #0 mentions the in-between testcases that crash in "different areas". Does the fix in this bug fix all of those or should we have spun off different bugs?
Group: security
Comment 4 claims all crashes were fixed.  There were a few "interesting"
assertions though that might be worth reporting if they still occur.
Group: security
Flags: in-testsuite?
Crash Signature: [@ nsStyleContext::FindChildWithRules]
Crashtest:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1b4983feaedc
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.