384373 - Crash [@ UpdateViewsForTree] with onerror, onblur, broadcaster and preferences

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Martijn Wargers (dead)]

Attachment: testcase

See testcase, which usually crashes Mozilla after a few reloads (testcase reloads automatically).

Talkback ID: TB33108793H
0x00000000
UpdateViewsForTree  [mozilla/layout/base/nscssframeconstructor.cpp, line 9646]
UpdateViewsForTree  [mozilla/layout/base/nscssframeconstructor.cpp, line 9655]
DoApplyRenderingChangeToTree  [mozilla/layout/base/nscssframeconstructor.cpp, line 9678]
ApplyRenderingChangeToTree  [mozilla/layout/base/nscssframeconstructor.cpp, line 9731]
InvalidateCanvasIfNeeded  [mozilla/layout/base/nscssframeconstructor.cpp, line 9789]
nsCSSFrameConstructor::ContentInserted  [mozilla/layout/base/nscssframeconstructor.cpp, line 8882]

The testcase also crashes on branch, but in a different place.:
Talkback ID: TB33108699G
nsSprocketLayout::GetAscent  [mozilla/layout/xul/base/src/nsSprocketLayout.cpp, line 1588]
nsBoxFrame::GetAscent  [mozilla/layout/xul/base/src/nsBoxFrame.cpp, line 987]
nsSprocketLayout::Layout  [mozilla/layout/xul/base/src/nsSprocketLayout.cpp, line 260]
etc..

Marking security sensitive for now, because it also crashes on branch.

Comment 1

[Martijn Wargers (dead)]

Attachment: a bit simpler testcase

Comment 2

[Martijn Wargers (dead)]

I have an unminized version of the testcase that crashes in:
https://crash-reports.mozilla.com/reports/report/index/6fb262c2-1c6c-11dc-91d9-001a4bd46e84
0  	nsCSSFrameConstructor::AdjustParentFrame(nsFrameConstructorState &,nsIContent *,nsIFrame * &,nsIAtom *,int,nsStyleContext *,nsFrameItems * &,nsFrameConstructorSaveState &,int &,int &)
1 	nsCSSFrameConstructor::ConstructFrameInternal(nsFrameConstructorState &,nsIContent *,nsIFrame *,nsIAtom *,int,nsStyleContext *,nsFrameItems &,int)
2 	nsCSSFrameConstructor::ConstructFrame(nsFrameConstructorState &,nsIContent *,nsIFrame *,nsFrameItems &)
3 	nsCSSFrameConstructor::ContentAppended(nsIContent *,int)
4 	PresShell::ContentAppended(nsIDocument *,nsIContent *,int)
5 	nsBindingManager::ContentAppended(nsIDocument *,nsIContent *,int)
6 	nsNodeUtils::ContentAppended(nsIContent *,int)
7 	nsGenericElement::doInsertChildAt(nsIContent *,unsigned int,int,nsIContent *,nsIDocument *,nsAttrAndChildArray &)
8 	nsGenericElement::InsertChildAt(nsIContent *,unsigned int,int)
9 	nsXULElement::InsertChildAt(nsIContent *,unsigned int,int)

This is a stacktrace similar to bug 349288, perhaps. Might be interesting to know.

Comment 3

[Martijn Wargers (dead)]

And I sometimes get stacktraces with nsCSSFrameConstructor::WipeContainingBlock on top of the stack.

Comment 4

[Boris Zbarsky [:bzbarsky]]

The error in question comes from a <xbl:field> evaluation, which happens at a time when it's not safe to run script.  So we do the node removal while frames are being constructed, and the rest is a mess of 0xdddddddd.

So we really need to fix bug 372769.

Comment 5

[Martijn Wargers (dead)]

What also might be interesting, with the unminimized testcase, I sometimes crash at [@ nsCSSFrameConstructor::ConstructFrame], which is also where bug 373756 and bug 360992 crashed.

Comment 6

[Samuel Sidler (old account; do not CC)]

Fixing bug 372769 won't fix this on the branch. The crash happens on the branch, but is it something we should worry about or does it appear to be a "safe" crash?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Please retest whether this is fixed?  I can't reproduce on trunk even without the patch for bug 372769...

Comment 8

[Martijn Wargers (dead)]

This was already worksforme, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007092705 Minefield/3.0a9pre

I mentioned that this crashed on branch, so I guess this has to remain security sensitive.

Comment 9

[Mats Palmgren (inactive)]

Landed both crashtests:
https://hg.mozilla.org/integration/mozilla-inbound/rev/5b9aacc58bdc

Comment 10

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/5b9aacc58bdc