330689 - Crash after heavy reloading, using insert with xbl [@ ClassifyWrapper]

Status: VERIFIED FIXED

(Core Graveyard :: XTF, defect)

Description

[Martijn Wargers (dead)]

See upcoming testcase, which crashes after 5 times reloading or so.

Talkback ID: TB16447391E
0xcb840f04
ClassifyWrapper   nsDOMClassInfo::BeginGCMark   nsDOMClassInfo::MarkReachablePreservedWrappers   nsDOMGCParticipantSH::Mark   XPC_WN_Helper_Mark   js_Mark   MarkGCThing   js_MarkGCThing   js_GC   js_ForceGC   nsAppShell::Run   nsAppStartup::Run   MSVCR80.dll + 0x8a21 (0x60218a21)

It doesn't crash in my debug build (which is winxp mingw build with cairo turned off).

Comment 1

[Martijn Wargers (dead)]

Attachment: testcase

Testcase crashes for me after repeatedly clicking on reload.

Comment 2

[Martijn Wargers (dead)]

Attachment: Testcase

Oops, previous file was wrong.

Comment 3

[aaronr]

recreated crash on debug trunk build (pulled 2006/05/01).  I don't see XForms on the call stack at all.

>	gklayout.dll!ClassifyWrapper(PLDHashTable * table=0x022835f0, PLDHashEntryHdr * hdr=0x036d83d0, unsigned int number=0x000000ba, void * arg=0x0012fad4)  Line 5176 + 0x10 bytes	C++
 	xpcom_core.dll!PL_DHashTableEnumerate(PLDHashTable * table=0x022835f0, PLDHashOperator (PLDHashTable *, PLDHashEntryHdr *, unsigned int, void *)* etor=0x01d6a980, void * arg=0x0012fad4)  Line 684 + 0x19 bytes	C
 	gklayout.dll!nsDOMClassInfo::BeginGCMark()  Line 5219 + 0x14 bytes	C++
 	gklayout.dll!nsDOMClassInfo::MarkReachablePreservedWrappers(nsIDOMGCParticipant * aParticipant=0x034b6110, JSContext * cx=0x036702d0, void * arg=0x00000000)  Line 5112 + 0xe bytes	C++
 	gklayout.dll!nsDOMGCParticipantSH::Mark(nsIXPConnectWrappedNative * wrapper=0x034b68c0, JSContext * cx=0x036702d0, JSObject * obj=0x033c7180, void * arg=0x00000000, unsigned int * _retval=0x0012fb4c)  Line 6809 + 0x16 bytes	C++
 	xpc3250.dll!XPC_WN_Helper_Mark(JSContext * cx=0x036702d0, JSObject * obj=0x033c7180, void * arg=0x00000000)  Line 1031	C++
 	js3250.dll!js_Mark(JSContext * cx=0x036702d0, JSObject * obj=0x033c7180, void * arg=0x00000000)  Line 4248 + 0x12 bytes	C
 	js3250.dll!MarkGCThingChildren(JSContext * cx=0x036702d0, void * thing=0x033c7180, unsigned char * flagp=0x033c8050, int shouldCheckRecursion=0x00000001)  Line 1283 + 0x25 bytes	C
 	js3250.dll!js_MarkGCThing(JSContext * cx=0x036702d0, void * thing=0x033c7180)  Line 1664 + 0x13 bytes	C
 	js3250.dll!gc_root_marker(JSDHashTable * table=0x00aef0f4, JSDHashEntryHdr * hdr=0x037da064, unsigned long num=0x00000002, void * arg=0x036702d0)  Line 1728 + 0x10 bytes	C
 	js3250.dll!JS_DHashTableEnumerate(JSDHashTable * table=0x00aef0f4, JSDHashOperator (JSDHashTable *, JSDHashEntryHdr *, unsigned long, void *)* etor=0x00d9b0f0, void * arg=0x036702d0)  Line 674 + 0x19 bytes	C
 	js3250.dll!js_GC(JSContext * cx=0x036702d0, unsigned int gcflags=0x00000000)  Line 2000 + 0x15 bytes	C
 	js3250.dll!js_ForceGC(JSContext * cx=0x036702d0, unsigned int gcflags=0x00000000)  Line 1753 + 0xd bytes	C
 	js3250.dll!JS_GC(JSContext * cx=0x036702d0)  Line 1853 + 0xb bytes	C
 	gklayout.dll!nsJSContext::Notify(nsITimer * timer=0x038802a8)  Line 2164 + 0xd bytes	C++
 	xpcom_core.dll!nsTimerImpl::Fire()  Line 405	C++
 	xpcom_core.dll!nsTimerManager::FireNextIdleTimer()  Line 637	C++
 	gkwidget.dll!nsAppShell::Run()  Line 142	C++
 	appcomps.dll!nsAppStartup::Run()  Line 208	C++
 	seamonkey.exe!main1(int argc=0x00000001, char * * argv=0x003d2fb0, nsISupports * nativeApp=0x003dec10)  Line 1248 + 0x22 bytes	C++
 	seamonkey.exe!main(int argc=0x00000001, char * * argv=0x003d2fb0)  Line 1750 + 0x25 bytes	C++
 	seamonkey.exe!__tmainCRTStartup()  Line 586 + 0x19 bytes	C
 	seamonkey.exe!mainCRTStartup()  Line 403	C
 	kernel32.dll!7c816d4f() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]	
 	kernel32.dll!7c8399f3() 	
 	gklayout.dll!nsImageLoadingContent::StringToURI(const nsAString_internal & aSpec={...}, nsIDocument * aDocument=0x00000000, nsIURI * * aURI=0x00000000)  Line 701 + 0xd bytes	C++
 	gklayout.dll!nsImageLoadingContent::StringToURI(const nsAString_internal & aSpec=, nsIDocument * aDocument=, nsIURI * * aURI=)  Line 701 + 0xd bytes	C++

Comment 4

[aaronr]

in ClassifyWrapper where it calls 
PL_DHashTableOperate(&sWrapperSCCTable, entry->participant->GetSCCIndex(), PL_DHASH_ADD));

it crashes because entry->participant's vtable is 0x00000005.  So either the participant object has been freed and become something else, or someone wrote over the memory.

But I don't see why this would involve us.  The testcase just has a lone xf:insert that does nothing.  It isn't bound to anything.  It isn't registered as a handler for any event.  It has no XBL or JS component to it.  All I can think of is that this might crash might happen for any XTF element.

Comment 5

[Allan Beaufour]

Confirmed on Firefox 1.5.0.3.

I agree with Aaron (comment 4). This must be XTF, not XForms.

Comment 6

[(not reading, please use [e-mail] instead)]

another possible duplicate of bug #345660?

Comment 7

[Martijn Wargers (dead)]

Attachment: Automatic reloading testcase

(In reply to comment #6)
> another possible duplicate of bug #345660?

No, I'm still crashing with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060802 Minefield/3.0a1

Comment 8

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

So in a debug build, I'm crashing even earlier (in DEBUG-only code):

in nsDOMClassInfo::PreserveNodeWrapper, |scriptable| is null, as is |sup|.  The classinfo returns null for GetHelperForLanguage -- and the classinfo implementation in question is an nsXTFGenericElementWrapper .  Is XTF hooked up to classinfo correctly?

Comment 9

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

XTF has its own classinfo implementation. That way XTF element implementations can easily define which interfaces are automatically visible to scripts.
XTF's classinfo doesn't implement nsIXPCScriptable, like nsDOMClassInfo.

Comment 10

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

I have no plans to work on this; the DOM code now depends on anything that has PreserveNodeWrapper called on it having classinfo that returns an nsIXPCScriptable with a mark callback that does the necessary work.

I have no plans to fix this.

Comment 11

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

I can take this.

Comment 12

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

Attachment: Using the default ::GetHelperForLanguage

Using the default ns(DOM)ClassInfo to get the helper should be ok.
At least I don't see any reason to re-implement nsIXPCScriptable unless
it would provide some new extension mechanisms (which aren't needed atm).

Comment 13

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 232031 [details] [diff] [review]
Using the default ::GetHelperForLanguage

Looks reasonable, if you make that error NS_ERROR_NOT_AVAILABLE.

Comment 14

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

Attachment: checked in

Comment 15

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

Comment on attachment 232082 [details] [diff] [review]
checked in

It would be great to get this to 1.8. Would prevent few XForms crashes (and XForms is pretty much the only user of XTF).

Comment 16

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

Comment on attachment 232082 [details] [diff] [review]
checked in

a=dbaron on behalf of drivers.  Please check in to MOZILLA_1_8_BRANCH and add the keyword fixed1.8.1 once you have done so.

Comment 17

[Martijn Wargers (dead)]

Verified fixed, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060806 Minefield/3.0a1

Comment 18

[Ria Klaassen (not reading all bugmail)]

Could this bug have caused Bug 409757 ?