Crash with evil xul testcase, using box, tooltip, object, etc [@ DoDeletingFrameSubtree]

VERIFIED FIXED in mozilla1.9alpha1

Status

()

Core
Layout
--
critical
VERIFIED FIXED
12 years ago
6 years ago

People

(Reporter: Martijn Wargers (dead), Assigned: bz)

Tracking

(Blocks: 1 bug, 5 keywords)

Trunk
mozilla1.9alpha1
x86
Windows XP
crash, regression, testcase, verified1.8.0.2, verified1.8.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8.1 +
blocking1.8.0.2 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: regression from bug 310638 [rft-dl], crash signature)

Attachments

(3 attachments)

(Reporter)

Description

12 years ago
See upcoming testcase, which crashes upon load in current trunk builds.
This looks like a regression, doesn't crash in 2006-01-26 build, but crashes in 2006-01-27 build, very likely a regression from bug 310638.
(Reporter)

Comment 1

12 years ago
Created attachment 210137 [details]
testcase (crashes on load)

Talkback ID TB14548920Z: 
DoDeletingFrameSubtree  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 9809]
DoDeletingFrameSubtree  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 9815]
DeletingFrameSubtree  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 9878]
nsCSSFrameConstructor::ContentRemoved  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 10064]
nsCSSFrameConstructor::ReinsertContent  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 9740]
nsCSSFrameConstructor::MaybeRecreateContainerForIBSplitterFrame  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 11646]
nsCSSFrameConstructor::ProcessRestyledFrames  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 10538]
nsCSSFrameConstructor::RestyleElement  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 10608]
nsCSSFrameConstructor::ProcessOneRestyle  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 13415]
nsCSSFrameConstructor::ProcessPendingRestyles  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 13467]
nsCSSFrameConstructor::RestyleEvent::HandleEvent  [c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 13534]
SHELL32.dll + 0x520c24 (0x778b0c24)
Not related to bug 288357?
Summary: Crash with evil xul testcase, using box, tooltip, object, etc → Crash with evil xul testcase, using box, tooltip, object, etc [@ DoDeletingFrameSubtree]
(Reporter)

Comment 3

12 years ago
No, not likely.
Mats, do you have time to look into this?

Is the issue here that we're failing to tear down the special siblings as you've commented elsewhere?  Note that in general we don't run into it because we reframe the containing block, but in this case there is no containing block...

Updated

12 years ago
Assignee: nobody → mats.palmgren
Flags: blocking1.8.1?
Created attachment 210277 [details]
Frame tree
(Reporter)

Updated

12 years ago
Blocks: 321107
Depends on: 322678

Comment 6

12 years ago
(In reply to comment #4)
> Is the issue here that we're failing to tear down the special siblings as
> you've commented elsewhere?

Yes, this is basically the same thing. We have two pending restyles
in ProcessPendingRestyles() for content that are descendents of a special
sibling (not the first in the chain), so the first restyle would destroy
the first special in the chain but since we don't destroy the following
the second restyle ended up doing a second DeletingFrameSubtree(), now on the
second special sibling that we left around.
In this frame there is a placeholder (the tooltip) that now have a null
out-of-flow.

Your patch for bug 322678 should fix this bug also.
I'm still a little worried that there are other (potentially bogus) frame
trees that would trigger this crash, so...

Comment 7

12 years ago
Created attachment 210679 [details] [diff] [review]
wallpaper, just in case...

... so maybe we should take this also, just in case.
(Until bug 323105 removes this function, but that might not land on branches?)
Fixed by patch in bug 322678.

Mats, I suspect the wallpaper would just delay crashes, not remove them, no?
Assignee: mats.palmgren → bzbarsky
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9alpha

Comment 9

11 years ago
(In reply to comment #8)
> Mats, I suspect the wallpaper would just delay crashes, not remove them, no?

I think it would actually avoid crashes that is caused by traversing the same
(sub)tree twice. Not that I have any reason to believe that it will occur though.
Hmm.. If you think that's possible, might be worth taking the patch on branch, I guess.
Using the testcase at https://bugzilla.mozilla.org/attachment.cgi?id=210137&action=view

this is Verified FIXED with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060209 Firefox/1.6a1
Status: RESOLVED → VERIFIED
Flags: blocking1.8.0.2?
Whiteboard: regression from bug 310638
Flags: blocking1.8.1?
Flags: blocking1.8.1+
Flags: blocking1.8.0.2?
Flags: blocking1.8.0.2+
Bug 322678 is on branches.
Keywords: fixed1.8.0.2, fixed1.8.1
Marking [rft-dl] (ready for testing in Firefox 1.5.0.2 release candidates)
Whiteboard: regression from bug 310638 → regression from bug 310638 [rft-dl]
Verified on the 1.8.0.2 branch using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060306 Firefox/1.5.0.2. No crash using the testcase. Adding relevant keyword.
Keywords: fixed1.8.0.2 → verified1.8.0.2
verified with Fx 2.0b2 builds from 22060821
Keywords: fixed1.8.1 → verified1.8.1
Crash Signature: [@ DoDeletingFrameSubtree]
You need to log in before you can comment on or make changes to this bug.