535898 - Firefox 3.6b5 Crash Report [@ nsPluginNativeWindow::CallSetWindow(nsCOMPtr<nsIPluginInstance>&) ]

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[chris hofmann]

#9 topcrash in early 3.6b5 data.  Looks like it migh have been around for awhile but is showing much higher freq. on 3.6b5 so far

https://crash-stats.mozilla.com/report/index/298382b2-f800-4e69-b0e1-a28362091218

Frame  	Module  	Signature [Expand]  	Source
0 		@0xa 	
1 	xul.dll 	nsPluginNativeWindow::CallSetWindow 	obj-firefox/dist/include/nsPluginNativeWindow.h:101
2 	xul.dll 	nsPluginNativeWindowWin::CallSetWindow 	modules/plugin/base/src/nsPluginNativeWindowWin.cpp:510
3 	xul.dll 	nsPluginHost::InstantiateEmbeddedPlugin 	modules/plugin/base/src/nsPluginHost.cpp:3265
4 	xul.dll 	nsObjectFrame::InstantiatePlugin 	layout/generic/nsObjectFrame.cpp:1021
5 	xul.dll 	nsObjectFrame::Instantiate 	layout/generic/nsObjectFrame.cpp:2088
6 	xul.dll 	nsObjectLoadingContent::Instantiate 	content/base/src/nsObjectLoadingContent.cpp:1767
7 	xul.dll 	nsAsyncInstantiateEvent::Run 	content/base/src/nsObjectLoadingContent.cpp:156
8 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:527
9 	xul.dll 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:170
10 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:182
11 	nspr4.dll 	PR_GetEnv 	
12 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:120
13 	firefox.exe 	__tmainCRTStartup 	obj-firefox/memory/jemalloc/crtsrc/crtexe.c:591
14 	kernel32.dll 	BaseProcessStart 

more reports at

https://crash-stats.mozilla.com/report/list?version=Firefox%3A3.6b5&query_search=signature&query_type=exact&query=&date=&range_value=2&range_unit=weeks&do_query=&signature=nsPluginNativeWindow%3A%3ACallSetWindow%28nsCOMPtr%3CnsIPluginInstance%3E%26%29&page=1


Correlation to startup
18 total crashes for nsPluginNativeWindow::CallSetWindow on 20091217-crashdata.csv
10 start up crashes inside 3 minutes

Correlation to releases

checking --- 20091217-crashdata.csv nsPluginNativeWindow::CallSetWindow
release total-crashes
              nsPluginNativeWindow::CallSetWindow crashes
                         pct.
all     227066  18      7.92721e-05
3.0.15  17135           0
3.0.16  22875   2       8.74317e-05
3.5.5   47876   3       6.26619e-05
3.5.6   80444           0
3.6b5   990     11      0.0111111
3.6b4   21208           0
3.6b3   670             0
3.6b2   739             0
3.6b1   2144            0

all releases
   2 3.0.16
   1 3.5
   1 3.5.2
   3 3.5.5
  11 3.6b5

os breakdown
9       0.5     Windows NT5.1.2600 Service Pack 3
3       0.166667        Windows NT6.0.6001 Service Pack 1
3       0.166667        Windows NT5.1.2600 Service Pack 2
2       0.111111        Windows NT6.1.7600
1       0.0555556       Windows NT6.0.6002 Service Pack 2

Comment 1

[chris hofmann]

Attachment: nov-dec17 nsPluginNativeWindow::CallSetWindow crash trend

overall volume is low but trend is up.  maybe this will decline with few release over the next several days.

Comment 2

[Marcia Knous [:marcia]]

Here is how I reproduced this crash using Firefox 3.6 B5:

1. Install the plugin from here: http://www.bing.com/maps/Help/VE3DInstall/
2. Visit the link in the URL field.
3. Click on the 3D widget in the map frame.
4. Crash.

Can reproduce 100% using Firefox 3.6 Beta 5 on Windows 7 x32.

Comment 3

[Marcia Knous [:marcia]]

http://crash-stats.mozilla.com/report/index/bp-047582f1-7c9e-4f76-a8a0-1cc4e2091221 is my crash report.

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

It seems from comment 0 like this isn't just a 1.9.2 crash, right?

Comment 5

[chris hofmann]

yes, there are instances of this signature on 3.5.x

yes, something has caused a large volume increase on the 3.6b5 bits.

here is a check on data from 12-20

checking --- 20091220-crashdata.csv nsPluginNativeWindow::CallSetWindow
release total-crashes
              nsPluginNativeWindow::CallSetWindow crashes
                         pct.
all     215848  102     0.000472555
3.0.15  6811            0
3.0.16  31577           0
3.5.5   18251   2       0.000109583
3.5.6   105854  2       1.88939e-05
3.6b5   16669   97      0.00581919
3.6b4   5000            0
3.6b3   644             0
3.6b2   661             0
3.6b1   2101            0

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Would be interesting to reproduce this in a debug build. It's strange that we seem to be crashing in the CallSetWindow itself, rather than a frame below it. I wonder if mPluginInstance somehow got to be dangling, or if socorro is lying to me.

What's really weird is that we're in the 'else' part of the CallSetWindow function, which should only happen if aPluginInstance is null. However if you look a couple of stack frames up, we should only be in this stack if the instance is *not* null.

So not sure what's going on with that.

Given that this can be reproduced, someone who's not on vacation should attempt to reproduce in a debug build :)

Do let me know if it's urgent and you want me to attempt to do so.

Marcia, given that this is bing.com, I'm guessing it's a silverlight plugin that's being used. Is that correct?

Comment 7

[Marcia Knous [:marcia]]

Yes, I believe that the latest version of the Silverlight plugin is installed on that machine but I can check. Would it help to get output from WinDbg?

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

Not blocking due to it not being a topcrasher, but bsmedberg will look into it and renominate if he finds a deeper systemic issue.

Comment 9

[Benjamin Smedberg]

->me at least temporarily

Comment 10

[Benjamin Smedberg]

Argh, I can't load this in Minefield because "3D is currently not supported for your browser. For a list of supported browsers, see Help."

Comment 11

[Josh Aas]

(In reply to comment #10)
> Argh, I can't load this in Minefield because "3D is currently not supported for
> your browser. For a list of supported browsers, see Help."

Can you avoid this by using the Firefox 3.5 UA string?

Comment 12

[Benjamin Smedberg]

I was able to get past the first part by switching the UA string, but after that it says "Problem loading Bing Maps 3D" and I don't know how to continue.

FWIW, this is supposedly not using the silverlight plugin but a separate "Virtual Earth 3D 4.00090316005 plugin for Mozilla"

Comment 13

[Benjamin Smedberg]

ok, I caught it in a release build with symbol server.

Inside of nsPluginHost::TrySetUpPluginInstance we end up deleting the nsNPAPIPlugin we just created:

>	xul.dll!nsNPAPIPlugin::~nsNPAPIPlugin()  Line 362	C++
 	xul.dll!nsNPAPIPlugin::`scalar deleting destructor'()  + 0x8 bytes	C++
 	xul.dll!nsUnicodeToUTF32Base::Release()  Line 210 + 0x18 bytes	C++
 	xul.dll!nsCOMPtr_base::~nsCOMPtr_base()  Line 82	C++
 	xul.dll!nsPluginHost::TrySetUpPluginInstance(const char * aMimeType=0x082c8738, nsIURI * aURL=0x094e25e0, nsIPluginInstanceOwner * aOwner=0x092fa660)  Line 3613 + 0xc0 bytes	C++

I haven't figured out why yet. The crash is just a result of having a nsNPAPIPluginInstance whose parent nsNPAPIPlugin has died.

Comment 14

[Benjamin Smedberg]

In nsPluginHost::GetPlugin:

    if (!plugin) {
      // Now lets try to get the entry point from an NPAPI plugin
      rv = CreateNPAPIPlugin(pluginTag, getter_AddRefs(plugin));
      if (NS_SUCCEEDED(rv))
        pluginTag->mEntryPoint = plugin;
    }

Somehow CreateNPAPIPlugin is setting `plugin` via the outparam but then returning a failure code. GetPlugin then returns NS_OK but doesn't set pluginTag->mEntryPoint so the plugin is deleted immediately after the instance is created.

Comment 15

[Benjamin Smedberg]

The google 3D plugin is returning "1" from NP_Initialize. I can backport

http://hg.mozilla.org/mozilla-central/diff/2ff020f77435/modules/plugin/base/src/nsNPAPIPlugin.cpp and
http://hg.mozilla.org/mozilla-central/diff/2ff020f77435/modules/plugin/base/src/nsPluginHost.cpp

to 1.9.2, which will cause the MS 3D plugin to "properly" fail to load. It would be nice to get an MS engineer to debug why the plugin is failing to load. This is a deep enough systemic issue that I think it should block, especially since the code's already written.

Comment 16

[Benjamin Smedberg]

Attachment: Backport e10s change to the branch, rev. 1

Running through tryserver, but I thought I'd get the patch posted in any case.

The reason this can't be reproduced on trunk is that http://hg.mozilla.org/mozilla-central/rev/2ff020f77435 was already merged from e10s and does the failure correctly.

Comment 17

[Johnny Stenback (:jst)]

Comment on attachment 419130 [details] [diff] [review]
Backport e10s change to the branch, rev. 1 

r=jst

I wonder if the reason for this plugin failing to initialize is that it attempts to use some of the XPCOM stuff that is no longer exposed to plugins in 3.6? One way to test for someone with a debugger would be to break in _getvalue() and see what it calls into us for etc.

Comment 18

[Benjamin Smedberg]

I am not able to push this until Saturday at the earliest, but if some workaholic doesn't celebrate Christmas properly, feel free to push this for me.

Comment 19

[timeless]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/80b81fd8452c

Comment 20

[Marcia Knous [:marcia]]

I know longer crash following the STR in Comment 2 using  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100105 Firefox/3.6 (.NET CLR 3.5.30729). Unfortunately the plugin doesn't initialize though, so the 3d maps will not work using Firefox 3.6.