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.

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?

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

(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

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.

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.

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.

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