434547 - NP_Shutdown called while firefox holds multiple instances of plugin scriptable interface

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[Tom Finegan]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0

Firefox 3 RC1 is loading scriptable plugIns twice per page load, and leaking instances of the scriptable interface from the first load of the plugIn.  

Note, the following two logs snips are from *one* page load.

First plugIn load:

[on2fp_init_logging]
 log started: Mon May 19 12:19:46 2008
 FlixPublisher v3.0.10.1 On2_Live_SDK v2.2.16.0
16:19:46.296::[NS_PluginInitialize]
16:19:46.296::[NS_NewPluginInstance]
16:19:46.296::[nsPluginInstance::nsPluginInstance]
16:19:46.296::[nsPluginInstance::init]
16:19:46.843::[nsPluginInstance::shut]
16:19:46.843::[nsScriptablePeer::SetInstance] null instance (mRefCnt=5)
16:19:46.937::[NS_DestroyPluginInstance]
16:19:46.937::[nsPluginInstance::~nsPluginInstance]
16:19:46.937::[nsScriptablePeer::SetInstance] null instance (mRefCnt=5)
16:19:46.937::[nsPluginInstance::~nsPluginInstance] calling kill()
16:19:47.046::[NS_PluginShutdown]

Second plugIn load:

[on2fp_init_logging]
 log started: Mon May 19 12:19:47 2008
 FlixPublisher v3.0.10.1 On2_Live_SDK v2.2.16.0
16:19:47.046::[NS_PluginInitialize]
16:19:47.046::[NS_NewPluginInstance]
16:19:47.046::[nsPluginInstance::nsPluginInstance]
16:19:47.046::[nsPluginInstance::init]


Of note in the first log are the mRefCnt value.  In stepping through the plugIn loads using a debugger (MS vs2005's in this case), xul.dll appears to be loading the plugIn, gathering interface pointers, then destroying the plugIn without releasing the interface pointers.

Xul.dll then goes on to call NS_PluginInitialize and creates a new instance of the plugIn.  




Reproducible: Always

Steps to Reproduce:
Visit the URL in the bug report using Firefox 3 RC 1 on Windows.
Actual Results:  
Plugin is loaded twice.  The first instance is never properly destroyed (xul.dll holds instances of the scriptable interface from the first load AFTER NS_PluginShutdown is called).

Expected Results:  
Plugin should only be loaded once. (All versions of Firefox 2 behave this way)

This same problem seems to break the Move Networks Move Media Player plugIn.  You can try out the Move Networks plugIn at http://www.movenetworks.com/

Comment 1

[Matthias Versen [:Matti]]

Plugin!=Extension

Comment 2

[Tom Finegan]

Corrected bug subject; core calls NP_Shutdown which is caller of NS_PluginShutdown.  Apologies for the mistake in the initial report.

Bug remains in FF3.0 RC2.

Comment 3

[Tom Finegan]

Spent some more time looking at this today...

Any comments from the Mozilla side would be greatly appreciated as I cannot find a workaround for this problem.  

The core of the issue is that the plugIn is being created twice when the object tag is injected into the page DOM.  This wouldn't be a problem if Release() were being called on all instances of the interfaces gathered by Firefox during the first creation of the plugIn, but that's not the case.  Xul.dll holds multiple instances of the plugIn interface.  The apparent resource leak is making it seemingly impossible to cope with the problem.

If it is not obvious from the initial report, this behavior is a regression in FF3.  FF2 does not show this behavior; the plugIn is created once per page load, and is not destroyed until the user navigates away from the page.

Comment 4

[Tom Finegan]

Still broken in rc3

Comment 5

[Matthias Versen [:Matti]]

RC2 is RC3, only the Mac Version contains a fix for an OS bug and FF3 final will be also the same as RC2.

Comment 6

[Shane Caraveo]

(In reply to comment #3)

> The core of the issue is that the plugIn is being created twice when the object
> tag is injected into the page DOM.  

That sounds like bug 438830, which has another bug linked that contains a patch.

Comment 7

[Tom Finegan]

That sounds like the problem.  Preventing the second instantiation, OR releasing all interface pointers from the first instantiation would fix things on my side.  

I believe your patch to be correct based on FF2 behavior.  

Shane, thanks for the information.

Comment 8

[Tom Finegan]

Attachment: Minefield .dmp

Minefield UA:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008063003 Minefield/3.1a1pre

Comment 9

[Tom Finegan]

Attachment: Minefield .extra

.extra file from the crash

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008063003 Minefield/3.1a1pre

Comment 10

[Tom Finegan]

Re bug 438830

Latest Minefield build is crashing.  The above .dmp and .extra attachments are from my last crash... 

The crash appears to be in xul.dll according to a loock at the stack in the VS2005 debugger...

To reproduce:

1. Load Minefield nightly on Windows
2. go to http://publisher.on2.com/jtv/flixpub_advanced.html
3. close the browser

Additional crash files have been submitted by the browser's crash reported.

Comment 11

[timeless]

http://developer.mozilla.org/en/docs/How_to_get_a_stacktrace_with_WinDbg

https://bugzilla.mozilla.org/show_bug.cgi?id=438830#c18 2008-06-27

sadly your .dmp is afaict from a nightly build and we only keep symbols for those for a couple weeks, so i can't do anything with it.

is this still happening?

Comment 12

[Benjamin Smedberg]

Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.