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

RESOLVED FIXED in mozilla1.9.2



8 years ago
7 years ago


(Reporter: chris hofmann, Assigned: Benjamin Smedberg)


({crash, regression, verified1.9.2})

Windows XP
crash, regression, verified1.9.2
Bug Flags:
blocking1.9.2 +

Firefox Tracking Flags

(status1.9.2 final-fixed)


(crash signature, URL)


(2 attachments)



8 years ago
#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

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

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
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

8 years ago
Created attachment 418455 [details]
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.


8 years ago
Flags: blocking1.9.2?
Keywords: crash, regression
Here is how I reproduced this crash using Firefox 3.6 B5:

1. Install the plugin from here:
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. is my crash report.
It seems from comment 0 like this isn't just a 1.9.2 crash, right?

Comment 5

8 years ago
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
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
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, I'm guessing it's a silverlight plugin that's being used. Is that correct?
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?
Not blocking due to it not being a topcrasher, but bsmedberg will look into it and renominate if he finds a deeper systemic issue.
Flags: blocking1.9.2? → blocking1.9.2-
Whiteboard: [3.6.c]


8 years ago
Flags: blocking1.9.2- → blocking1.9.2?
Whiteboard: [3.6.c] → [3.6.x]
Flags: blocking1.9.2? → blocking1.9.2-

Comment 9

8 years ago
->me at least temporarily
Assignee: nobody → benjamin

Comment 10

8 years ago
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

8 years ago
(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

8 years ago
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

8 years ago
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

8 years ago
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

8 years ago
The google 3D plugin is returning "1" from NP_Initialize. I can backport and

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.
Flags: blocking1.9.2- → blocking1.9.2+

Comment 16

8 years ago
Created attachment 419130 [details] [diff] [review]
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 was already merged from e10s and does the failure correctly.
Attachment #419130 - Flags: review?(jst)
Attachment #419130 - Flags: review?(joshmoz)
Comment on attachment 419130 [details] [diff] [review]
Backport e10s change to the branch, rev. 1 


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.
Attachment #419130 - Flags: review?(jst) → review+
Severity: normal → critical
OS: Mac OS X → Windows XP

Comment 18

8 years ago
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.
Keywords: checkin-needed
Whiteboard: [3.6.x] → [3.6.x][needs landing 1.9.2]

Comment 19

8 years ago
status1.9.2: --- → final-fixed
Last Resolved: 8 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [3.6.x][needs landing 1.9.2] → [3.6.x]


8 years ago
Attachment #419130 - Flags: review?(joshmoz) → review+
Whiteboard: [3.6.x]
Target Milestone: --- → mozilla1.9.3a1
Target Milestone: mozilla1.9.3a1 → mozilla1.9.2
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.
Keywords: verified1.9.2
Crash Signature: [@ nsPluginNativeWindow::CallSetWindow(nsCOMPtr<nsIPluginInstance>&) ]
You need to log in before you can comment on or make changes to this bug.