1.29 KB, text/html
18.30 KB, application/zip
2.08 KB, patch
Mike Schroepfer: approval1.8.1+
|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...
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.
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
This will have to wait for 184.108.40.206
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 220.127.116.11
Comment on attachment 235697 [details] [diff] [review] Patch rev. 1 we're building now, I guess this will have to be 18.104.22.168 after all.
Comment on attachment 235697 [details] [diff] [review] Patch rev. 1 a=schrep for drivers.
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
Landed on MOZILLA_1_8_0_BRANCH at 2006-10-05 16:56 PDT.
v.fixed on 1.8.0 branch with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:22.214.171.124pre) Gecko/20061020 Firefox/126.96.36.199pre, no crash.
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.