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

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Martijn Wargers (dead)]

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.

Comment 1

[Martijn Wargers (dead)]

Attachment: testcase, crashes on load

Comment 2

[Martijn Wargers (dead)]

Attachment: zip file of original testcase and all in-between testcases

Comment 3

[Mats Palmgren (inactive)]

Patch coming up...

Comment 4

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1

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.

Comment 5

[Mats Palmgren (inactive)]

sg: we're using random memory and in some cases overwrite the stack.

Comment 6

[Boris Zbarsky [:bzbarsky]]

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.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Landing it on the trunk is fine -- these pieces are the easy ones to merge.

Comment 8

[Boris Zbarsky [:bzbarsky]]

If dbaron's ok with it, then go ahead and land on trunk too, sure.

Comment 9

[Mats Palmgren (inactive)]

Landed on trunk at 2006-08-28 00:30 PDT.

-> FIXED

Comment 10

[Daniel Veditz [:dveditz]]

This will have to wait for 1.8.0.8

Comment 11

[Daniel Veditz [:dveditz]]

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

Comment 12

[Daniel Veditz [:dveditz]]

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.

Comment 13

[Mike Schroepfer]

Comment on attachment 235697 [details] [diff] [review]
Patch rev. 1

a=schrep for drivers.

Comment 14

[Mats Palmgren (inactive)]

Landed on MOZILLA_1_8_BRANCH at 2006-08-31 09:57 PDT.

Comment 15

[Daniel Veditz [:dveditz]]

Restoring lost blocking flag

Comment 16

[Daniel Veditz [:dveditz]]

Comment on attachment 235697 [details] [diff] [review]
Patch rev. 1

approved for 1.8.0 branch, a=dveditz for drivers

Comment 17

[Mats Palmgren (inactive)]

Landed on MOZILLA_1_8_0_BRANCH at 2006-10-05 16:56 PDT.

Comment 18

[Jay Patel [:jay]]

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.

Comment 19

[Daniel Veditz [:dveditz]]

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?

Comment 20

[Mats Palmgren (inactive)]

Comment 4 claims all crashes were fixed.  There were a few "interesting"
assertions though that might be worth reporting if they still occur.

Comment 21

[Mats Palmgren (inactive)]

Crashtest:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1b4983feaedc

Comment 22

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/1b4983feaedc