Dialog "Plugin Container for Firefox has stopped working" displayed on DeleteSession #225

Open
florentbr opened this Issue Sep 13, 2016 · 15 comments

Projects

None yet

8 participants

@florentbr
florentbr commented Sep 13, 2016 edited

On Windows, the driver doesn't properly quit Firefox which leads to a crash message box:

image

I found out that the driver doesn't terminate the process plugin-container.exe under firefox.exe.

Config:
Windows 8.1, Firefox 48.0.2, geckodriver-v0.10.0-win64, python client 3.0.0.b2

To reproduce:

from selenium.webdriver.firefox.service import Service
from selenium.webdriver.firefox.remote_connection import FirefoxRemoteConnection

# start service
service = Service("geckodriver.exe")
service.start()

# launch firefox
executor = FirefoxRemoteConnection(remote_server_addr=service.service_url)
sessionId = executor.execute('newSession', {})['sessionId']

# quit firefox
executor.execute('quit', {'sessionId': sessionId})  # Displays the dialog "Plugin Container for Firefox has stopped working"

Expected:

The driver should dispose all the processes under geckodriver.exe when the session is terminated.

@andreastt
Member

Does this happen consistently?

I have noticed frequent crashes on Linux when using officially branded builds, which leads me to suspect they are set up differently. However, I’m not sure yet if this is the cause.

@florentbr
florentbr commented Sep 13, 2016 edited

@andreastt, it happens when Firefox has the child process named plugin-container.exe. Previously this process was only present when the page had a plugin, like Flash. But since recently, this process is always present. I also noticed that this process is not present when Firefox starts with a blank page (about:blank) and present when Firefox starts with the home page (about:home), which is the case with v0.10.0.

I can also manually reproduce the same issue by just killing firefox.exe when the process plugin-container.exe is present.

@andreastt
Member

Thank you for the excellent explanation!

I don’t know why plugin-container.exe spawns when loading about:home, but I suspect what happens here is that we try to forcibly quit Firefox in geckodriver or that we interrupt the subprocess.

Either way we trigger crash detection which causes the dialogue you included a screenshot of on Windows, or a the Firefox crash dialogue on Windows that I’ve seen recently.

The fact that you pinpointed that this only seems to happen when on about:home was a very useful clue, because the immediate issue will get resolved by c49e5cd (coming in 0.11.0).

However, to solve the underlying issue I feel we should experiment with not using eForceQuit. Now that I know that calling quit whilst on about:home triggers this crash, I will try to find a solution.

@andreastt
Member
andreastt commented Sep 13, 2016 edited

I could be mistaken about why I see the officially branded Firefox crash on my Linux system. The crash report it generates indicates there is something wrong with X syncing:

Without MOZ_X_SYNC:

[10505] ###!!! ABORT: X_ShmAttach: BadAccess (attempt to access private resource denied); 3 requests ago: file /builds/slave/m-rel-l64-00000000000000000000/build/src/toolkit/xre/nsX11ErrorHandler.cpp, line 157

With MOZ_X_SYNC:

[10856] ###!!! ABORT: X_SyncSetCounter: XSyncBadCounter; sync: file /builds/slave/m-rel-l64-00000000000000000000/build/src/toolkit/xre/nsX11ErrorHandler.cpp, line 157

I think this is unrelated to this issue as it also happens on starting Firefox, not on calling quitApplication in Marionette.


Edit: I’ve filed bug 1302500 about the things mentioned in this comment. It is not related to this GitHub issue.

@andreastt
Member

I just filed and patched bug 1302503 to allow GeckoDriver#quitApplication to take no parameters.

@florentbr

@andreastt, I tried to send the command quitApplication directly to marionette with a session started with the gecko driver. The browser closes immediately without any issue and the child process plugin-container.exe is properly terminated:

import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.1', 11174))
s.send(b'48:[0,1,"quitApplication",{"flags":["eForceQuit"]}]')
s.recv(1024)
s.close()

So the issue is probably not with marionette but with the gecko driver itself.

@avivasp
avivasp commented Sep 20, 2016 edited

My solution (Java source):

DesiredCapabilities desiredCapabilities = ...;
FirefoxProfile profile = new FirefoxProfile();
profile.setPreference("browser.startup.homepage","about:blank");
desiredCapabilities.setCapability(FirefoxDriver.PROFILE, profile);
WebDriver webDriver = new FirefoxDriver(desiredCapabilities);`
@ewdob
ewdob commented Sep 26, 2016

Even though I have set the startup page to "about:blank", the plugin Container Error is still present for me. So I don't think this solution works for everybody.
If anybody has some other solutions I would be very grateful.

@andreastt
Member

@avivasp The homepage the browser starts on was corrected, as I said earlier in this thread, in c49e5cd which will be available in the next release of geckodriver.

Your fix only works incidentally because the default homepage in official branded Firefox builds causes the plugin container to be started for some reason. We are no closer to a real fix to this problem.

The next thing worth investigating is if the rust-mozrunner library is signalling the browser process in a way that causes the plugin container to error.

@ewdob
ewdob commented Sep 26, 2016

I tried a run on a Windows 10 vm, and surprisingly the error didnt occur anymore.

@florentbr

@andreastt, I managed to avoid the crash message by setting these environement variables:

SET MOZ_CRASHREPORTER=0
SET MOZ_CRASHREPORTER_DISABLE=1
SET MOZ_CRASHREPORTER_NO_REPORT=1
SET XRE_NO_WINDOWS_CRASH_DIALOG=1
REM SET GNOME_DISABLE_CRASH_DIALOG=1

I also defined these preferences to avoid the initial page which starts the plugin container:

user_pref("browser.startup.page", 0);
user_pref("browser.startup.homepage", "about:blank");
user_pref("browser.startup.homepage_override.mstone", "ignore");
user_pref("browser.usedOnWindows10", true);
@gerixx
gerixx commented Nov 22, 2016

Now "firefox.exe" crashes when using quit() with Firefox 50.
Setting environment variable XRE_NO_WINDOWS_CRASH_DIALOG=1 avoids the dialog.

Log output:
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
[Child 8756] ###!!! ABORT: Aborting on channel error.: file c:/builds/moz2_slave/m-rel-w32-00000000000000000000/build/src/ipc/glue/MessageChannel.cpp, line 2056
Nov 22, 2016 9:26:28 AM org.openqa.selenium.os.UnixProcess destroy
SEVERE: Unable to kill process with PID 7288

@iamcodylee

I encounter this issue as well, but only on Windows 7
I use same scripts, same version Java, everything same except OS.
but surprisingly this issue only occur on Windows 7, not occur on Windows 8
also try to set the startup page to "about:blank"
the Plugin Container Error is still present on Windows 7

@neeasade
neeasade commented Dec 5, 2016

Encountering @gerixx 's issue on Windows Server 2012 R2, Firefox 50. Also seeing OP's issue in Firefox 49 on the same OS.

@robinsmathewgit

Is this issue still not resolved? I am facing the same issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment