Jim Jeffery not reading bug-mail 1/2/11 Reporter
	Description • 11 years ago

The plugin-container is silently crashes when opening a 'New e10s Window' from Nightly builds.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0

m-c win32 build, latest Nightly/or Tinderbox build
No Crash-reporter is being presented.

Following info in the Win7 Event Viewer:

Faulting module name: mozalloc.dll, version: 31.0.0.5195, time stamp: 0x532f012a
Exception code: 0x80000003
Fault offset: 0x000012cb
Faulting process id: 0x52cc
Faulting application start time: 0x01cf46f0306f089b
Faulting application path: J:\Program Files (x86)\Nightly\plugin-container.exe
Faulting module path: J:\Program Files (x86)\Nightly\mozalloc.dll
Report Id: 7f0060c7-b2e3-11e3-9316-00242155d461

STR:
1.  Open Nightly/hourly Build
2.  File->New e10S Window 
3.  Open cnn.com in a new tab in that window
4.  Close the e10s window - not sure if merely opening CNN is causing the container to crash, or closure of the actual window.

	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 1 • 10 years ago

So I was able to reproduce this, and here's my current theory:

The content process spawns a plugin process whenever it needs to instantiate a plugin.

When the content process is shutdown, say by a window close, it gets to this point:

http://hg.mozilla.org/mozilla-central/file/74985b96c4c3/dom/ipc/ContentChild.cpp#l1455

Now, I might be wrong about this, but I believe that this _exit(0); occurs without waiting for any plugin instances to be shut down. So the content process exits and dies.

And the plugin process probably tries to send messages, and realizes that there's nobody listening on the other end, and hits a MOZ_CRASH via NS_RUNTIMEABORT in MessageChannel::OnChannelErrorFromLink.

And there's your crash.

I _think_ this will be solved by bug 641685, which puts plugin process management back into the parent process.

How's my math on this, johns?

	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 2 • 10 years ago

Adjusting estimate, because I'm pretty sure bug 641685 will fix this.

	John Schoenick [:johns]
	Comment 3 • 10 years ago

(In reply to Mike Conley (:mconley) from comment #2)
> Adjusting estimate, because I'm pretty sure bug 641685 will fix this.

Agreed, though I would keep this open so we can re-test when that's ready

	CAK
	Comment 4 • 10 years ago

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0

As per Comment 0

Reproducible 100% on cnn.com (and https://www.cyta.com.cy/telephony-internet)

No crash reports.

From Win Problem Details:

  Problem Event Name:		APPCRASH
  Application Name:		plugin-container.exe
  Application Version:		35.0.0.5367
  Application Timestamp:	5411b744
  Fault Module Name:		mozalloc.dll
  Fault Module Version:		35.0.0.5367
  Fault Module Timestamp:	5411b3eb
  Exception Code:		80000003
  Exception Offset:		000012d5
  OS Version:			6.1.7601.2.1.0.256.48
  Locale ID:			1033
  Additional Information 1:	0a9e
  Additional Information 2:	0a9e372d3b4ad19135b953a78882e789
  Additional Information 3:	0a9e
  Additional Information 4:	0a9e372d3b4ad19135b953a78882e789

The error occurs NOT when closing tab but when closing Nightly.

	martin
	Comment 5 • 10 years ago

From what I observe with process explorer, if a plugin gets run in a new process
closing firefox first makes the top level processes go away and then the bottom level plugin-containter.exe crashes.
I do _not_ see this crash when closing tabs.

Firefox.exe  ( closes normally , shuts down second)
|--------->Plugin-Container.exe ( closes normally, shuts down first )
                     |--------->Plugin-Container.exe (crashes when ending after its parents, last in sequence)


So this may be a timing issue, i.e. the toplevel process probably should wait until its descendants are done shutting down, or if this is meant to happen asynchronously, then there seems to be a bug in cleaning up the plugin-container.exe that runs the plugins.


Flash Version  15.0.0.189 (Current on Okt 10th 2014)
Silverlight  5.1.30514.0
Java 10.67.2.1

Steps to reproduce:
Create new Profile
Turn on e10s
dom.ipc.processCount is set to 1 (default)
Browse to a page containing a plugin that is out of process enabled
eg http://bubblemark.com/silverlight2.html or 
http://helpx.adobe.com/flash-player.html (press check now button to activate flash
Close the browser with these 2 pages open and the plugins active.
Computer will report plugin-container.exe crash.

Expected behavior:
No plugin-container.exe crash


Other observations:
If you close the 2 Tabs hosting the plugins, browse pluginless pages and wait for some time, then the bottom level plugin-container.exe will shutdown gracefully without crash.

	martin
	Comment 6 • 10 years ago

Further testing with dom.ipc.processCount set to 5. and 5 tabs with various plugins.
This reveals that, I can reproduce the crash when closing a tab.
The reason for this is that each of the tabs runs in its own plugin-container.exe and has a child process for the plugin. 
Close a tab and the exe hosting the page will end before the exe hosting the plugin, resulting in a crash of the latter.

	Jim Mathies [:jimm]
	Comment 7 • 10 years ago

independent of dom.ipc.processCount changes, this should have been fixed by bug e10s-plugin-ipc.