See upcoming testcase, which crashes current branches, it doesn't crash current trunk build. If desired, I can reduce the testcase. Talkback ID: TB20840965W nsFrameItems::AddChild [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 744] nsCSSFrameConstructor::ConstructFrameByDisplayType [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 6891] nsCSSFrameConstructor::CantRenderReplacedElement [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 11028] CantRenderReplacedElementEvent::HandleEvent [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp, line 4090] 0x778b0c24 0x00200064 0x0c718d08
Ctrl++ to zoom the testcase seems to trigger the crash bug 343206 again on trunk.
Created attachment 230900 [details] testcase2 A different testcase that also triggers this same crash in branch builds.
This looks like a safe null-deref on the branch and doesn't happen on the trunk. Any objection to removing the security-sensitive flag on this bug?
I don't see the trunk crash described in comment 2 anymore.
(In reply to comment #4) > This looks like a safe null-deref on the branch and doesn't happen on the > trunk. Any objection to removing the security-sensitive flag on this bug? No, I don't have any objection to that (if you want to remove the security-sensitive flag, then I have no objection, in general).
CantRenderReplacedElement() calls ConstructFrameByDisplayType() which only handles a limited set of cases since it's normally called at the end of ConstructFrameInternal() (after XUL frame creation an such). We have <object style="display: -moz-grid-line;"> which isn't handled so we fall into the UNREACHED at the end, since we haven't created a frame in this case we will call AddChild with a null frame. This is a 100% null-deref, so not a security problem. http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/base/nsCSSFrameConstructor.cpp&rev=MOZILLA_1_8_BRANCH&root=/cvsroot&mark=6893,6905#6842
Created attachment 263844 [details] [diff] [review] Patch rev. 1
So maybe this should not be fixed on branch then? I mean, iirc, I hit crash a lot on branch. It might be that after this fix, I could hit something worse (not that I test that much on branch, unfortunately).
> It might be that after this fix, I could hit something worse I don't think so. The patch results in the content in this case will have no frame at all, which is a common and well tested state. I think the risk of this patch enabling new and untested code paths is low. OTOH, it's highly unlikely that any real web pages will trigger this crash by accident...
Comment on attachment 263844 [details] [diff] [review] Patch rev. 1 Sure, I guess. I hate the branch. ;)
Comment on attachment 263844 [details] [diff] [review] Patch rev. 1 approved for 126.96.36.199 and 188.8.131.52, a=dveditz for release-drivers
Checked in to MOZILLA_1_8_BRANCH: layout/base/nsCSSFrameConstructor.cpp: 1.1110.6.77 Checked in to MOZILLA_1_8_0_BRANCH: layout/base/nsCSSFrameConstructor.cpp: 1.1184.108.40.206.56
verified fixed on 220.127.116.11 using Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:18.104.22.168pre) Gecko/20070705 BonEcho/22.214.171.124pre ID:2007070504 and Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199pre) Gecko/2007070503 BonEcho/188.8.131.52pre on Fedora F7 - no crash on testcases - adding verified keyword
This is verified fixed on 184.108.40.206
(In reply to comment #16) > This is verified fixed on 220.127.116.11 > Sorry, this was on Linux. I should have specified this.
crash test landed http://hg.mozilla.org/mozilla-central/rev/b480ed41fe22