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




11 years ago
10 years ago


(Reporter: shaver, Assigned: smaug)


Windows Vista
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)




(1 attachment, 1 obsolete attachment)

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


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!
Flags: blocking1.9?
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.
Component: Layout → DOM
QA Contact: layout → general
Created attachment 307319 [details] [diff] [review]

Is the crash easily reproduceable?
Any chance kungFuDeathGrip helps here? (Didn't even compile, though I can't
reproduce the crashes)
Is this reproducible? Does it happen a lot?

Smaug, you should probably at least hold a kungFuDeathGrip(this) in nsDocument::FlushPendingNotifications as well.
Assignee: nobody → Olli.Pettay
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
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.
I can't reproduce it now, I'll keep trying. :/
Created attachment 308403 [details] [diff] [review]
kungFuDeathGrip in nsDocument::FlushPendingNotifications

So, if anyone can reproduce the crash, would be good to test if this helps.
Attachment #307319 - Attachment is obsolete: true
Not blocking on this as people apparently can't reproduce it. If that changes, re-nominate...
Flags: blocking1.9+ → blocking1.9-
(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


10 years ago
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.