543770 - [OOPP] Java applets cause multiple crashing plugin messages [@ npdeploytk.dll@0x3943 ]

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Tobias (:Tobbi) Markus]

When opening http://www.java.com/en/download/help/testvm.xml for example, you get multiple Crashing plugin messages (at least 3). However, the plugin content itself seems to load fine. 

You cannot see exactly what the cause is from the crash report:
Example: http://crash-stats.mozilla.com/report/index/a9b5a1f8-818d-4fe9-b99a-e4e282100202

Comment 1

[Tobias (:Tobbi) Markus]

This is happening for me on Java 6 Update 18, with 
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20100202 Minefield/3.7a1pre

Comment 2

[Benjamin Smedberg]

>	npdeploytk.dll!1000393c() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for npdeploytk.dll]	
 	npdeploytk.dll!100018ec() 	
 	npdeploytk.dll!10001ab7() 	
 	npdeploytk.dll!100037ae() 	
 	npdeploytk.dll!10022f26() 	
 	xul.dll!mozilla::plugins::PluginModuleChild::NPN_CreateObject(_NPP * aNPP=0x02cd90a8, NPClass * aClass=0x1002d16c)  Line 1523 + 0x4 bytes	C++
 	npdeploytk.dll!10003803() 	
 	npdeploytk.dll!10001578() 	
 	xul.dll!mozilla::plugins::PluginModuleChild::AnswerPPluginInstanceConstructor(mozilla::plugins::PPluginInstanceChild * aActor=0x02cd9080, const nsCString & aMimeType={...}, const unsigned short & aMode=1, const nsTArray<nsCString> & aNames={...}, const nsTArray<nsCString> & aValues={...}, short * rv=0x00ccd7e8)  Line 1477 + 0x26 bytes	C++
 	xul.dll!mozilla::plugins::PPluginModuleChild::OnCallReceived(const IPC::Message & msg={...}, IPC::Message * & reply=0x00000000)  Line 437 + 0x1c bytes	C++
 	xul.dll!mozilla::ipc::RPCChannel::DispatchIncall(const IPC::Message & call={...})  Line 374	C++
 	xul.dll!mozilla::ipc::RPCChannel::Incall(const IPC::Message & call={...}, unsigned int stackDepth=0)  Line 359	C++
 	xul.dll!mozilla::ipc::RPCChannel::OnMaybeDequeueOne()  Line 293 + 0xd bytes	C++
 	xul.dll!MessageLoop::RunTask(Task * task=0x00000000)  Line 327	C++
 	xul.dll!MessageLoop::DeferOrRunPendingTask(const MessageLoop::PendingTask & pending_task={...})  Line 337	C++
 	xul.dll!MessageLoop::DoWork()  Line 434 + 0x7 bytes	C++
 	xul.dll!mozilla::ipc::DoWorkRunnable::Run()  Line 78	C++
 	xul.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x00ccd974)  Line 528	C++
 	xul.dll!mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate * aDelegate=0x00ccfa20)  Line 143	C++
 	xul.dll!MessageLoop::RunInternal()  Line 212	C++
 	xul.dll!MessageLoop::RunHandler()  + 0x1efc2e bytes	C++
 	xul.dll!MessageLoop::Run()  Line 169	C++
 	xul.dll!nsBaseAppShell::Run()  Line 180	C++
 	xul.dll!nsAppShell::Run()  Line 240	C++
 	xul.dll!XRE_RunAppShell()  Line 475 + 0x6 bytes	C++

Comment 3

[Benjamin Smedberg]

    File: npjp2.dll
    Version: 6.0.180.7
    Next Generation Java Plug-in 1.6.0_18 for Mozilla browsers

Comment 4

[Calvin Cheung]

It's working for me on windows XP sp3 with 
JRE 6u18 b07 and Minefield 3.7a1pre.

Debugger shows the following jre libraries are loaded upon running the applet in the testvm page: http://www.java.com/en/download/help/testvm.xml

'firefox.exe': Loaded 'C:\Program Files\Java\jre6\bin\new_plugin\npdeploytk.dll', No symbols loaded.
'firefox.exe': Loaded 'C:\WINDOWS\system32\apphelp.dll', Symbols loaded.
'firefox.exe': Loaded 'C:\Program Files\Java\jre6\bin\new_plugin\npjp2.dll', No symbols loaded.
'firefox.exe': Loaded 'C:\WINDOWS\system32\MSVCR71.DLL', No symbols loaded.

Is this a Vista specific issue?

Comment 5

[Calvin Cheung]

I've also tried with Vista Ultimate sp2 32-bit and it works fine.

Comment 6

[Benjamin Smedberg]

->me for the moment, I've caught the crash in record-and-replay on Vista. I also sent a minidump to Calvin in the hopes of getting a better stack trace.

Comment 7

[Benjamin Smedberg]

In recording immediately after NPP_Destroy we enumerate and deallocate the NPObject in question:

mozilla::plugins::PluginModuleChild::DeallocNPObject(aNPObj=0x01323464)
mozilla::plugins::PluginModuleChild::DeallocForInstance(d=0x0082a420, userArg=0x00812a60)
nsTHashtable<nsDOMStorageEntry>::s_EnumStub(table=0x00802a00, entry=0x0082a420, number=0x00000001, arg=0x014ef55c)
PL_DHashTableEnumerate(table=0x00802a00, etor=0x69958720, arg=0x014ef55c)
nsTHashtable<mozilla::plugins::PluginModuleChild::NPObjectData>::EnumerateEntries(enumFunc=0x014ef628, userArg=0x00812a60)
mozilla::plugins::PluginModuleChild::DeallocNPObjectsForInstance(instance=0x00812a60)
mozilla::plugins::PluginModuleChild::PluginInstanceDestroyed(aActor=0x00812a60, rv=0x014ef5c4)
mozilla::plugins::PluginInstanceChild::AnswerNPP_Destroy(aResult=0x014ef5c4)

Subsequently in the same enumeration, we deallocate a different object. The Java NPClass.deallocate callback tries to release the object which was already destroyed:

mozilla::plugins::PluginModuleChild::DeallocNPObject(aNPObj=0x01323464)
mozilla::plugins::PluginModuleChild::NPN_ReleaseObject(aNPObj=0x01323464)
NPDEPLOYTK.dll!10001be0() 	
NPDEPLOYTK.dll!10002377() 	
NPDEPLOYTK.dll!10001940() 	
mozilla::plugins::PluginModuleChild::DeallocNPObject(aNPObj=0x01325d9c)
mozilla::plugins::PluginModuleChild::DeallocForInstance(d=0x0082a480, userArg=0x00812a60)
nsTHashtable<nsDOMStorageEntry>::s_EnumStub(table=0x00802a00, entry=0x0082a480, number=0x00000005, arg=0x014ef55c)
PL_DHashTableEnumerate(table=0x00802a00, etor=0x69958720, arg=0x014ef55c) 	nsTHashtable<mozilla::plugins::PluginModuleChild::NPObjectData>::EnumerateEntries(enumFunc=0x014ef628, userArg=0x00812a60)
mozilla::plugins::PluginModuleChild::DeallocNPObjectsForInstance(instance=0x00812a60)
mozilla::plugins::PluginModuleChild::PluginInstanceDestroyed(aActor=0x00812a60, rv=0x014ef5c4)
mozilla::plugins::PluginInstanceChild::AnswerNPP_Destroy(aResult=0x014ef5c4)

I have verified that the hashtable we're enumerating does not mutate.

jst, how is this supposed to work? Is the plugin supposed to avoid calling NPN_ReleaseObject on an object which has already been deallocated because the instance is gone? Or should the host have some sort of protection against this case?

Comment 9

[Johnny Stenback (:jst)]

As best as I can tell our code, both with and w/o OOPP, calls invalidate on the object before calling deallocate, and once an object is invalidated it should be considered having no valid members etc, so deallocate on an invalidated object shouldn't do anything any more. This is all from fading memory, so I'm not sure how this lines up with the assumptions made by the Java plugin developers, but I've also not seen this problem before OOPP, so I'm not sure what to make of that.

Comment 10

[Benjamin Smedberg]

I fixed this in bug 544074: we now maintain a hash of all objects which are being destroyed, and ignore any NPN_ReleaseObject calls which are mid-destroy.