766130 - Flash hangs trying to shutdown during CreatePlugin

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[Benoit Girard (:BenWa)]

My dad reports repeated 60 second hangs throughout the day. I asked him to grab a profile:

Main thread of browser process:
http://people.mozilla.com/~bgirard/cleopatra/?report=AMIfv96slSGI2H8xfFEXBBXIqjUD-yHQocPMeSGqsfK03Znbw09q3vJeuuCX1ibkafcw-inQsSv01veN9OVWZDduQY3HYWw4mhc4PLQ6D9pCefLLkSRSkD84WGnMMa9XuU3UTVL68RSTgf4Y0cnD3AHXt02pyIoMgA

I don't understand this stack, it appears that we enter CreatePlugin but then we release the references to the plugin and decide to shutdown. Is it a valid way to shutdown the plugin?

After hanging 30 seconds we generate a minidump:
https://crash-stats.mozilla.com/report/index/e0b813b4-02cb-4bc0-96e8-3f1572120619

Both sides are waiting on 'NtWaitForMultipleObjects', presumably caused by Flash's sandbox architecture?

Comment 1

[Benjamin Smedberg]

Is there a particular URL which causes this? The interesting things going on here are:

1) Web content appears to be showing some kind of modal window, either an alert/prompt or using window.openDialog
2) In the nested event loop of the modal dialog we're running the nsAsyncInstantiateEvent because at the time the plugin was originally set up, we were in the middle of layout and couldn't safely instantiate it. So far this is a little weird but probably ok. I'd really like to know whether the plugin is in the modal window or the parent which opened it. It may not be "safe" to instantiate a plugin for the parent window while the child window is in a modal loop.

3) At this point we appeared to be unsuccessful in creating the plugin (not a particular instance, but setting up a Flash subprocess itself). The hang report appears to be saying that we're hitting the OOM check at http://hg.mozilla.org/projects/profiling/annotate/d1c38dc26377/dom/plugins/base/nsNPAPIPlugin.cpp#l439

which is kinda absurd-feeling to me.

Comment 2

[Benoit Girard (:BenWa)]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #1)
> The hang
> report appears to be saying that we're hitting the OOM check at
> http://hg.mozilla.org/projects/profiling/annotate/d1c38dc26377/dom/plugins/
> base/nsNPAPIPlugin.cpp#l439

What makes you think it's line 1439? Couldn't any of the return statements release the reference implicitly?

Comment 3

[Steven Michaud [:smichaud] (Retired)]

By the way, these stacks are from some version of Windows (I can't tell which one).

Comment 4

[Benjamin Smedberg]

Well, the hang minidump assigns it to that line, see https://crash-stats.mozilla.com/report/index/412f9900-1b0e-40ea-92cd-13aec2120619

Comment 5

[Benoit Girard (:BenWa)]

Asked a few clarification over the phone, unfortunately this is on his office desktop machine and I have no access to debug.

(In reply to Steven Michaud from comment #3)
> By the way, these stacks are from some version of Windows (I can't tell
> which one).

Windows Server 2008 R2 SP1

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #1)
> Is there a particular URL which causes this? The interesting things going on
> here are:
> 
> 1) Web content appears to be showing some kind of modal window, either an
> alert/prompt or using window.openDialog

There's no modal window dialog or pop up.

> 2) In the nested event loop of the modal dialog we're running the
> nsAsyncInstantiateEvent because at the time the plugin was originally set
> up, we were in the middle of layout and couldn't safely instantiate it. So
> far this is a little weird but probably ok. I'd really like to know whether
> the plugin is in the modal window or the parent which opened it. It may not
> be "safe" to instantiate a plugin for the parent window while the child
> window is in a modal loop.

There no window or any page in particular that trigger this. It happens everywhere including during google search, intranet site, or daily surfing. This problem is also occurring on the intranet site which does not use Flash. This doesn't rule out something triggered by a background tab. 

> 
> 3) At this point we appeared to be unsuccessful in creating the plugin (not
> a particular instance, but setting up a Flash subprocess itself). The hang
> report appears to be saying that we're hitting the OOM check at
> http://hg.mozilla.org/projects/profiling/annotate/d1c38dc26377/dom/plugins/
> base/nsNPAPIPlugin.cpp#l439
> 
> which is kinda absurd-feeling to me.

According to about:crashes the instability started on June 14, which may of been when he received the flash update. His current version is:
Flash version 11.3.3.300.257

Comment 6

[Benjamin Smedberg]

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