Chromedriver quit() method doesn't close all chrome.exe processes #6317

nemirof · 2018-08-22T09:32:07Z

OS: Windows 7 (64-bit)
Selenium Version: 3.14
Browser: Chrome, Firefox

Browser Version:
Google Chrome 68.0.3440.106 (Official Build) (64-bit)

Expected Behavior -

chromedriver.exe processes to be closed.
geckodriver.exe processes to be closed.

Actual Behavior -

Hello guys, since a month ago, we're expecting some kind of problems trying to kill the chromedriver.exe and geckodriver.exe processes.

We usually run several tests simultaneously and when the TestSuite ends, many chromedriver.exe / geckodriver.exe processes still there on the system.

This problem causes the system goes slower and slower, causing at the end the system crashes.

This is the message we're receiving from the driver:

Trace init:

Starting ChromeDriver 2.41.578737 (49da6702b16031c40d63e5618de03a32ff6c197e) on port 36461
Only local connections are allowed.
ago 21, 2018 1:59:03 PM org.openqa.selenium.remote.ProtocolHandshake createSession
INFO: Detected dialect: OSS

When we try to quit() the driver:

INFO: Unable to drain process streams. Ignoring but the exception being swallowed follows.
org.apache.commons.exec.ExecuteException: The stop timeout of 2000 ms was exceeded (Exit value: -559038737)
	at org.apache.commons.exec.PumpStreamHandler.stopThread(PumpStreamHandler.java:295)
	at org.apache.commons.exec.PumpStreamHandler.stop(PumpStreamHandler.java:181)
	at org.openqa.selenium.os.OsProcess.destroy(OsProcess.java:135)
	at org.openqa.selenium.os.CommandLine.destroy(CommandLine.java:153)
	at org.openqa.selenium.remote.service.DriverService.stop(DriverService.java:223)
	at org.openqa.selenium.remote.service.DriverCommandExecutor.execute(DriverCommandExecutor.java:95)
	at org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:548)
	at org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:605)
	at org.openqa.selenium.remote.RemoteWebDriver.quit(RemoteWebDriver.java:448)
	at utils.Utils.quit(Utils.java:2783)
	at utils.Utils.guardarResultado(Utils.java:2816)
	at com.bbva.ebcf.pon.LimitePonMismoUsuarioFirmando.tearDown(LimitePonMismoUsuarioFirmando.java:163)
	at junit.framework.TestCase.runBare(TestCase.java:140)
	at junit.framework.TestResult$1.protect(TestResult.java:110)
	at junit.framework.TestResult.runProtected(TestResult.java:128)
	at junit.framework.TestResult.run(TestResult.java:113)
	at junit.framework.TestCase.run(TestCase.java:124)
	at junit.framework.TestSuite.runTest(TestSuite.java:243)
	at junit.framework.TestSuite.run(TestSuite.java:238)
	at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

ago 22, 2018 9:31:43 AM org.openqa.selenium.os.OsProcess destroy
SEVERE: Unable to kill process java.lang.ProcessImpl@70eecdc2

This is not happening every single time, for example, if we try to reproduce the error in oir IDE's it is almost impossible. It seems that is something related whith too many chrome processes running at the same time (My guess).

This is the method we call in every single test we run (in @after ) we close and quit the driver:

	public static void quitDriver(WebDriver driver)
	{

		try
		{

			driver.close();
		}
		catch(Exception e1)
		{
			
		}

		try
		{
			driver.quit();
		}
		catch(Exception e)
		{

		}

	}

And this is the way we start the driver:

	System.setProperty("webdriver.chrome.driver", "lib/chromedriver.exe");

	String downloads = new File("downloads").getAbsolutePath();				
	HashMap<String, Object> chromePrefs = new HashMap<String, Object>();
	chromePrefs.put("profile.default_content_settings.popups", 0);
	chromePrefs.put("download.default_directory", downloads);	
	chromePrefs.put("download.prompt_for_download", false);
	chromePrefs.put("download.directory_upgrade", true);

	ChromeOptions options = new ChromeOptions();
	options.setExperimentalOption("prefs", chromePrefs);
	options.addArguments("enable-automation");
	options.addArguments("start-maximized");
	options.addArguments("disable-popup-blocking");
	options.addArguments("disable-default-apps"); 
	//options.addArguments("--no-sandbox");
	options.addArguments("ignore-certificate-errors");
	
	LoggingPreferences logPrefs = new LoggingPreferences();
	logPrefs.enable(LogType.PERFORMANCE, Level.ALL);
	
	options.setCapability(CapabilityType.LOGGING_PREFS, logPrefs);
	options.setCapability(CapabilityType.ACCEPT_SSL_CERTS, true);
	
	driver = new ChromeDriver(options);

We have tried almost everything (we are 5 testing engineers working on the same project) and the processes are still there.

Windows can't kill the process with taskkill /f /im chromedriver.exe

So.... Please, if someone have some idea, we would appreciate it. We have read a lot, before opening this issue.

Thank you guys! Thank you community!

The text was updated successfully, but these errors were encountered:

circa10a · 2018-08-22T19:48:09Z

Also having similar issue with seleniumJS 4 / Chrome 68 / chromedriver 2.38 & 2.41 via headless where driver.quit() isn't working:

 NoSuchSessionError: This driver instance does not have a valid session ID (did you call WebDriver.quit()?) and may no longer be used.

richman555 · 2018-08-22T20:48:15Z

We opened a similar type issue (6314) yesterday except for IE. I can't guarantee its the same issue, but the resulting behavior seems to be the same. This issue started about a week ago after taking a MS update. Otherwise, wish I could be more helpful!

JackWangAndRose · 2018-09-04T11:53:54Z

We met same issue,On chrome and chromedriver

tictac-freshmint · 2018-09-05T10:07:17Z

I have the same issue, both on Windows 7 and Windows 10 since a few weeks. I already tried a lot of things, nothing worked yet. For instance I tried dozens of ways to terminate chromedriver.exe, as an administrator, on commandline with various commands, with PowerShell and with tools from Sysinternals. Only a Windows reboot kills these processes, log off and log on does not terminate them.

Also I disabled the virus scanner and reverted to previous versions of Selenium and webdrivers, but it did not help.

It happens with webdrivers for Chrome, IE and Edge (we do not use other browsers), apparently only since a few weeks. Sometimes the processes can be terminated however when ¨driver.quit()¨ is executed. Maybe it has to do with an automatically installed Windows update? In a forum someone wrote that he uninstalled

More and more zombie processes slow down the test execution performance and tests fail because of timeouts then.

There is a blog https://blogs.technet.microsoft.com/markrussinovich/2005/08/17/unkillable-processes/ which explains the reasons for that in Windows and how it can be analyzed by debugging. But I am no expert on this and I do not know yet if the Windows administators will allow to install the ¨Windows Debugging Tools¨. But maybe someone else is familiar with this and can install them in order to investigate the reason?

Also interesting seemed to be this page: https://randomascii.wordpress.com/2018/02/11/zombie-processes-are-eating-your-memory/ It mentions a tool called ¨FindZombieHandles¨, but our very secured system prevents me to use such a tool. Maybe someone else has the oppurtunity and can report if it helps to understand why exactly the webdriver processes cannot be terminated?

In a forum which I cannot find anymore someone wrote that after uninstalling a recent Windows update (KB something with 818 I think at the end) the problem with webdriver zombie processes could be solved. But that update was not installed on our computer. Now I see here #6314 which says that it occured after KB4339093, which is installed on our machine since a few weeks. I maybe try to convince the admins to uninstall it.

barancev · 2018-09-05T20:31:19Z

As far as it hits three drivers (IEDriverServer, chromedriver and geckodriver) developed independently by different people, and taking into account the fact that we did not touch OS subsystem of Java binding for half a year, the issue must be caused by a change in operating system.

I suppose Selenium can't kill a driver process for the same (unknown yet) reason that you can't kill it from the task manager. Something prevents the process from being stopped.

Try to check if reverting KB4339093 actually resolves the issue. Of course it's just a workaround, but we have to identify the root cause before trying to fix the issue.

tictac-freshmint · 2018-10-01T09:33:06Z

In our case the problem seems to be gone since last week. Maybe there was some Windows update which fixed it.

dewanprakash · 2018-10-03T09:42:53Z

We are facing identically same issue with
Selenium v3.8.1
Chrome drvier v2.41.x
Chrome browser v69
Windows 7

claytonwinders · 2018-10-16T15:22:33Z

Facing a similar issue:
selenium-webdriver 4.0.0-alpha
Chrome driver 2.42
Chrome browser v69
AWS Linux

Using an async function in an express get method in node, after running successfully once and calling driver.quit() cannot call again due to chromedriver still running

temadivnich · 2018-11-20T10:34:07Z

Hi all
We met the same issue, do you know when it will be solved ?

MattKeenum · 2018-11-29T16:39:14Z

We are encountering the same issue. 3 Google Chrome (chrome.exe) process still sits in memory after calling driver.quit(). They tend to take between 25-30% CPU and roughly 20-25 MB in memory each. Currently, calling taskkill on chrome.exe is the only way to get rid of em.

Selenium 3.12.1
ChromeDriver 2.43.0
Chrome Browser 70.0.3538.110

heyitsmesuraj · 2018-12-12T12:53:32Z

I have the same issue when page timeout reached and there is no exception for Webdriver.Quit() and does not kill the processes.
OneTimeSetUp: OpenQA.Selenium.WebDriverException : The HTTP request to the remote WebDriver server for URL http://localhost:55323/session/f4b61f62299ebcf485d710ff65d9184c/element/0.1432089089670756-3/click timed out after 60 seconds.
----> System.Net.WebException : The request was aborted: The operation has timed out.
Exception doesn't have a stacktrace

hacrot3000 · 2018-12-13T07:10:30Z

I have same issue, lot of chrome cause my test server freeze because runs out of ram.

schreibd · 2018-12-20T13:57:16Z

Same here.
Want to run my tests in a jenkins build and need to be sure these processes get killed after methodcall...
However, setting the webDriver to null kills the process for me

MattKeenum · 2018-12-20T14:26:04Z

We have been able to fix the issue of the chrome.exe zombie processes being left over. We were passing "--no-sandbox" argument to the ChromeDirver. Removing this argument from the driver initialization solved the issue. We no longer have the zombie processes left over after calling driver.quit

spetrovas · 2018-12-28T21:20:40Z

In our code we always had "--no-sandbox" COMMENTED OUT and the problem is still there. I'm wondering why no one addresses this issue in the Selenium code; here is a scriplet from org.openqa.selenium.os.OsProcess class; have a look at the comment:
`public int destroy() {
SeleniumWatchDog watchdog = executeWatchdog;
watchdog.waitForProcessStarted();

// I literally have no idea why we don't try and kill the process nicely on Windows. If you do,
// answers on the back of a postcard to SeleniumHQ, please.
if (!thisIsWindows()) {
  watchdog.destroyProcess();
  watchdog.waitForTerminationAfterDestroy(2, SECONDS);
}

if (isRunning()) {
  watchdog.destroyHarder();
  watchdog.waitForTerminationAfterDestroy(1, SECONDS);
}`

MattKeenum · 2018-12-29T22:06:16Z

@spetrovas Try removing the "no-sandbox" argument

andiramuttakim · 2018-12-30T12:50:00Z

My headless chrome cannot run without --no-sandbox flag.
Already setup a user as mentioned on this page, but it didn't work.

spetrovas · 2019-01-02T20:08:44Z

Sorry, about confusion - I meant to say "In our code we always had "--no-sandbox" COMMENTED OUT and the problem is still there."

I corrected my previous comment.

The error in the node log file:
[2019-01-02 22:03:36] [SEVERE] Unable to kill process java.lang.ProcessImpl@f0de26

is coming from this class and method:
org.openqa.selenium.os.OsProcess class
public int destroy()

What I was trying to point out is this comment in the code:
public int destroy() {
SeleniumWatchDog watchdog = executeWatchdog;
watchdog.waitForProcessStarted();

// I literally have no idea why we don't try and kill the process nicely on Windows. If you do,
// answers on the back of a postcard to SeleniumHQ, please.
if (!thisIsWindows()) {
watchdog.destroyProcess();
watchdog.waitForTerminationAfterDestroy(2, SECONDS);
}

if (isRunning()) {
watchdog.destroyHarder();
watchdog.waitForTerminationAfterDestroy(1, SECONDS);
}
. . . .
}

Our Se Grid runs on Windows 10 (AWS WS):
Selenium 3.14.0
Chromedriver 2.43
Google Chrome 71.0.3578.98 (Official Build) (64-bit) (cohort: Stable)

It might be the problem related to Windows but it still can be the problem in Selenium code as well. From the code it is apparently seen that there is no proper process.destroy implemented for Windows platform, and then the process is simply tried to be destroyed forcibly.

And my question is - is anyone going to look into that problem?

laurinkeithdavis · 2019-01-14T20:27:31Z

We are having this same issue as well. Why was this closed?

cgoldberg · 2019-01-14T20:42:21Z

Why was this closed?

please submit all ChromeDriver issues to: https://bugs.chromium.org/p/chromedriver/issues/

fenixadar · 2019-01-24T08:26:13Z

https://stackoverflow.com/questions/10752512/get-pid-of-browser-launched-by-selenium/13650111
there is the answer. I have same issue, but i sloved.
u can try"ChromeDriverService service = ChromeDriverService.createDefaultService();" before create ChromeDriver,u will find this issue is not exists

spetrovas · 2019-02-04T21:09:23Z

That does not help when using remote web driver with Se Grid which provides remote service.

AMG888 · 2019-03-13T11:56:12Z

Just noting for anyone caught out by a similar experience. I found a number of zombie instances of chrome persisted after I aborted builds running on jenkins.

Naturally, if they are aborted mid flight, they don't hit the teardown method and terminate processes using .close and/or .quit

Taskkill mopped them up but maybe worth bearing in mind

claytonwinders · 2019-03-13T12:05:23Z

We moved to using the standalone-chrome docker container for testing. This allowed us to have timeouts on the docker container when tests seemed to either escape all the catches for .close() or didn't work. It has been a bit difficult to work into codeception integration but for standalone selenium tests with python or node it has been great

barancev added D-chrome OS-windows C-java labels Aug 25, 2018

tictac-freshmint mentioned this issue Sep 10, 2018

IEDriverServer.exe process does not end after installing Microsoft Update (KB4339093). #6314

Closed

barancev mentioned this issue Oct 3, 2018

chromedriver.exe is not killable in widows after calling driver.quit() #6474

Closed

pizhanska mentioned this issue Nov 1, 2018

update driver quit to kill processes for gecko/chrome #6606

Closed

cgoldberg closed this as completed Dec 29, 2018

lock bot locked and limited conversation to collaborators Aug 14, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Chromedriver quit() method doesn't close all chrome.exe processes #6317

Chromedriver quit() method doesn't close all chrome.exe processes #6317

nemirof commented Aug 22, 2018 •

edited

Loading

circa10a commented Aug 22, 2018 •

edited

Loading

richman555 commented Aug 22, 2018

JackWangAndRose commented Sep 4, 2018

tictac-freshmint commented Sep 5, 2018

barancev commented Sep 5, 2018

tictac-freshmint commented Oct 1, 2018

dewanprakash commented Oct 3, 2018

claytonwinders commented Oct 16, 2018

temadivnich commented Nov 20, 2018

MattKeenum commented Nov 29, 2018

heyitsmesuraj commented Dec 12, 2018

hacrot3000 commented Dec 13, 2018

schreibd commented Dec 20, 2018 •

edited

Loading

MattKeenum commented Dec 20, 2018

spetrovas commented Dec 28, 2018 •

edited

Loading

MattKeenum commented Dec 29, 2018 •

edited

Loading

andiramuttakim commented Dec 30, 2018

spetrovas commented Jan 2, 2019 •

edited

Loading

laurinkeithdavis commented Jan 14, 2019

cgoldberg commented Jan 14, 2019

fenixadar commented Jan 24, 2019

spetrovas commented Feb 4, 2019

AMG888 commented Mar 13, 2019

claytonwinders commented Mar 13, 2019

Chromedriver quit() method doesn't close all chrome.exe processes #6317

Chromedriver quit() method doesn't close all chrome.exe processes #6317

Comments

nemirof commented Aug 22, 2018 • edited Loading

Expected Behavior -

Actual Behavior -

circa10a commented Aug 22, 2018 • edited Loading

richman555 commented Aug 22, 2018

JackWangAndRose commented Sep 4, 2018

tictac-freshmint commented Sep 5, 2018

barancev commented Sep 5, 2018

tictac-freshmint commented Oct 1, 2018

dewanprakash commented Oct 3, 2018

claytonwinders commented Oct 16, 2018

temadivnich commented Nov 20, 2018

MattKeenum commented Nov 29, 2018

heyitsmesuraj commented Dec 12, 2018

hacrot3000 commented Dec 13, 2018

schreibd commented Dec 20, 2018 • edited Loading

MattKeenum commented Dec 20, 2018

spetrovas commented Dec 28, 2018 • edited Loading

MattKeenum commented Dec 29, 2018 • edited Loading

andiramuttakim commented Dec 30, 2018

spetrovas commented Jan 2, 2019 • edited Loading

laurinkeithdavis commented Jan 14, 2019

cgoldberg commented Jan 14, 2019

fenixadar commented Jan 24, 2019

spetrovas commented Feb 4, 2019

AMG888 commented Mar 13, 2019

claytonwinders commented Mar 13, 2019

nemirof commented Aug 22, 2018 •

edited

Loading

circa10a commented Aug 22, 2018 •

edited

Loading

schreibd commented Dec 20, 2018 •

edited

Loading

spetrovas commented Dec 28, 2018 •

edited

Loading

MattKeenum commented Dec 29, 2018 •

edited

Loading

spetrovas commented Jan 2, 2019 •

edited

Loading