1.29 KB, text/html
18.30 KB, application/zip
2.08 KB, patch
|Details | Diff | Splinter Review|
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
Created attachment 235697 [details] [diff] [review] 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.
sg: we're using random memory and in some cases overwrite the stack.
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.
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
Last Resolved: 13 years ago
Resolution: --- → FIXED
This will have to wait for 184.108.40.206
Flags: blocking220.127.116.11? → blocking18.104.22.168?
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 22.214.171.124
Attachment #235697 - Flags: approval126.96.36.199+
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 188.8.131.52 after all.
Attachment #235697 - Flags: approval184.108.40.206+ → approval220.127.116.11?
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.
Restoring lost blocking flag
Comment on attachment 235697 [details] [diff] [review] Patch rev. 1 approved for 1.8.0 branch, a=dveditz for drivers
Attachment #235697 - Flags: approval18.104.22.168? → approval22.214.171.124+
Landed on MOZILLA_1_8_0_BRANCH at 2006-10-05 16:56 PDT.
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:126.96.36.199pre) Gecko/20061020 Firefox/188.8.131.52pre, no crash.
Keywords: fixed184.108.40.206 → verified220.127.116.11
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 4 claims all crashes were fixed. There were a few "interesting" assertions though that might be worth reporting if they still occur.
Crash Signature: [@ nsStyleContext::FindChildWithRules]
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.