150764 - [EA] Crash on XPCOM scripted plugin exit when going to java enable site [@ nsCOMPtr_base::~nsCOMPtr_base]

Status: VERIFIED DUPLICATE of bug 148889

(Core Graveyard :: Plug-ins, defect, P2)

Description

[Jeff Price]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
BuildID:    2002053012

The browser crashes when navigating to a java enabled site, after using a 
scriptable plugin (and have used the scripting).  There seems to be a reference 
counting issue in recent builds (after NS 6.2.3) as the final release never 
occurs/the destuctor never gets called.  I have seen this in NS 7 PR 1, and 
Mozilla 2002053012.

Reproducible: Always
Steps to Reproduce:
1.Build the attached plugin
2.Install it
3.Load the included html file
4)Click the link (Should popup "retval: 5")
5)navigate to: java.sun.com

Actual Results:  The browser crashes

Expected Results:  Unload the sample plugin, load the java rich page

Comment 1

[Jeff Price]

Attachment: sample XPCOM enabled plugin

you'll need to change the paths to the the correct header files and xpidl...

Comment 2

[Jeff Price]

Attachment: the callstack from the crash

Comment 3

[Jeff Price]

crashes with an access violation in xpcom.dll.  You may have to delete 
components.reg and restart a couple of times to get scripting to work 
correctly.  This is either another bug, or me not know the correct way to get 
Mozilla to acknowledge a new plugin...  I haven't tried forcing a refresh in js 
yet.

Comment 4

[Peter Lubczynski]

Jeff, can you get Talkback to fire when you crash? Enter your e-mail address and
take note of the 'TalkbackID' and we can lookup a more meaningful stack with
symbols. Thanks!

Comment 5

[av (gone)]

Taking for investigation.

Comment 6

[Jeff Price]

I sent in 2 events from Mozilla (TB7215329Z and TB7215264Y), and 1 from 
Netscape 7 PR 1 (TB7215520K).  Let me know if you need anything else...  like a 
precompiled version of the plugin I used.  It just ocurred to me that the 
generated header files I have may be out of date...  But I would expect a more 
immedate crash if it was bad assumptions about the vtable.  I'll pull the 
latest source and try that as well.

Comment 7

[Peter Lubczynski]

Thanks for the Talkback info! 

Yup, you are seeing what others are seeing:

nsCOMPtr_base::~nsCOMPtr_base
[d:\builds\seamonkey\mozilla\xpcom\glue\nsCOMPtr.cpp, line 64]
XPCWrappedNativeProto::~XPCWrappedNativeProto
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativeproto.cpp,
line 89]
DyingProtoKiller
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcjsruntime.cpp, line 201]
JS_DHashTableEnumerate [d:\builds\seamonkey\mozilla\js\src\jsdhash.c, line 600]
XPCJSRuntime::GCCallback
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcjsruntime.cpp, line 543]
DOMGCCallback [d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp,
line 1623]
js_GC [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 1349]
js_ForceGC [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 981]
JS_GC [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 1657]
nsJSContext::Notify
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 1573]
nsTimerManager::FireNextIdleTimer
[d:\builds\seamonkey\mozilla\xpcom\threads\nsTimerImpl.cpp, line 593]
nsAppShell::Run [d:\builds\seamonkey\mozilla\widget\src\windows\nsAppShell.cpp,
line 134]

This is probably related to bug 148889 which I think could be related to bug
144838 which I think are all related to bug 109281.

Question: As a test, if you intentionally leak (extra addref) your class which
implements nsIClassInfo, does the crash go away? Note the TalkbackID, I wonder
if it moved?

Comment 8

[Jeff Price]

I tried 1 and 2 extra addref's, and then 1 fewer.  They all crashed, TB7216912G 
is the case you asked for with 1 extra addref.  I didn't submit on the others, 
but can if you think it would be useful.  It feels like the plugin dll may be 
being released before the final release is called (instant access 
violation)...  I haven't dug into the Mozilla code though.  Just a hunch.

Comment 9

[Jeff Price]

FYI- The plugin does get a DLL_PROCESS_DETACH message to DllMain just before 
the crash.

Comment 10

[Adam Hauner]

BTW bug 148889 with same stack signature shouldn't be related? (bug 118279 has
also same stack)

Comment 11

[Peter Lubczynski]

Hm.....if we are unloading your DLL, perhaps you can try asking us to keep it in
memory:

Does it help if you call NPN_SetValue(mInstance, NPPVpluginKeepLibraryInMemory,
true)?

Might need to add this npapi.h:
NPPVpluginKeepLibraryInMemory = 13 /* available in Mozilla 1.0 */

Comment 12

[Jeff Price]

Calling NPN_SetValue(instance, NPPVpluginKeepLibraryInMemory,(void*)true) 
prevents the crash.  Furthermore, the final release is called and the 
scriptable class's destructor fires and all is well.  The timing of the 
destructor call is right when the crash would have occured, so I would strongly 
suspect the js to native scripting layer is holding a reference longer than it 
should.  I tried scanning the code last night, but it would take me weeks to 
come up to speed...

Comment 13

[Peter Lubczynski]

moving discussion to bug 148889.

*** This bug has been marked as a duplicate of 148889 ***

Comment 14

[shrirang khanzode]

vd