420086 - hangs and crashes under nsDocument::BeginUpdate (under FlushTags) with OpenLaszlo demos

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect, P2)

Description

[Mike Shaver (:shaver emeritus)]

Loading various DHTML demos there (LZPIX and the Amazon one, in this case) have caused me to crash

bp-11cfeed1-e607-11dc-80f2-001a4bd43ef6

and hang:

WARNING: Frame IP not in any known module. Following frames may be wrong.
0012ee0c 604fb57c 0xcc00000
0012ee14 606c0afc xul!nsCOMPtr_base::assign_with_AddRef(class nsISupports * rawPtr = 0x02d6b410)+0xc [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\obj-fx-trunk\xpcom\build\nscomptr.cpp @ 89]
0012ee1c 6052bd1a xul!nsCOMPtr<nsIDocument>::operator=(class nsIDocument * rhs = 0x02d6b410)+0x9 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\obj-fx-trunk\dist\include\xpcom\nscomptr.h @ 715]
0012ee44 606b8e5e xul!nsDocument::BeginUpdate(unsigned int aUpdateType = 0x35f7890)+0x9a [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\content\base\src\nsdocument.cpp @ 2706]
0012ee50 605c62b0 xul!mozAutoDocUpdate::mozAutoDocUpdate(class nsIDocument * aDocument = 0x605f10d0, unsigned int aUpdateType = 0x5e57480, int aNotify = 218103808)+0x22 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\obj-fx-trunk\dist\include\content\nsidocument.h @ 1079]
0012ee84 605f10d0 xul!SinkContext::FlushTags(void)+0x48 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\content\html\document\src\nshtmlcontentsink.cpp @ 1355]
0012ee8c 609bf62b xul!HTMLContentSink::FlushTags(void)+0x1f [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\content\html\document\src\nshtmlcontentsink.cpp @ 3228]
0012ee94 60756d11 xul!HTMLContentSink::FlushPendingNotifications(mozFlushType aType = 1617196554 (No matching enumerant))+0x1c [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\content\html\document\src\nshtmlcontentsink.cpp @ 3206]
0012eed8 6064760a xul!nsDocument::FlushPendingNotifications+0x20e051
0012eee4 60658743 xul!nsGlobalWindow::GetFrames(class nsIDOMWindow ** aFrames = 0x030b1810)+0x27 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\dom\src\base\nsglobalwindow.cpp @ 5069]
0012eef8 605016e7 xul!NS_InvokeByIndex_P(class nsISupports * that = 0x030b1810, unsigned int methodIndex = 0x11, unsigned int paramCount = 1, struct nsXPTCVariant * params = 0x0012efa0)+0x27 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp @ 102]
0012ef54 60126920 xul!XPCWrappedNative::CallMethod(class XPCCallContext * ccx = 0x0cc00000, XPCWrappedNative::CallMode mode = 51058704 (No matching enumerant))+0x557 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp @ 2339]
0012efac 600cb2c9 js3250!JS_GetReservedSlot+0x50
0012f014 60504e56 nspr4!PR_Unlock(struct PRLock * lock = <Memory access error>)+0x39 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\nsprpub\pr\src\threads\combined\prulock.c @ 356]
00000000 00000000 xul!XPC_WN_CallMethod(struct JSContext * cx = <Memory access error>, struct JSObject * obj = <Memory access error>, unsigned int argc = <Memory access error>, long * argv = <Memory access error>, long * vp = <Memory access error>)+0x196 [e:\builds\tinderbox\fx-trunk\winnt_5.2_depend\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp @ 1470]

I don't always get it, but it happens often enough to frustrate my attempts to use the demos!

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Operating on a deleted nsIDocument*, maybe?  The stack in breakpad shows BeginUpdate calling _purecall (i.e., making a pure virtual function call).

It would be helpful to know what was on the stack below.

Seems like this belongs in Content rather than Layout, though.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Attachment: kungFuDeathGrip

Is the crash easily reproduceable?
Any chance kungFuDeathGrip helps here? (Didn't even compile, though I can't
reproduce the crashes)

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Is this reproducible? Does it happen a lot?

Smaug, you should probably at least hold a kungFuDeathGrip(this) in nsDocument::FlushPendingNotifications as well.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Hey, how did this get assigned to me :) I was just suggesting a possible fix
based on the stack trace. I can't reproduce this.

Comment 5

[Mike Shaver (:shaver emeritus)]

I can't reproduce it now, I'll keep trying. :/

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Attachment: kungFuDeathGrip in nsDocument::FlushPendingNotifications

So, if anyone can reproduce the crash, would be good to test if this helps.

Comment 7

[Johnny Stenback (:jst)]

Not blocking on this as people apparently can't reproduce it. If that changes, re-nominate...

Comment 8

[Carsten Book [:Tomcat]]

(In reply to comment #7)
> Not blocking on this as people apparently can't reproduce it. If that changes,
> re-nominate...
> 

also not able to reproduce this crash with the test url and Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b5pre) Gecko/2008031506 Minefield/3.0b5pre