Issue 1934 in selenium: WebDriver is not deleting the profile directory after test exits

[sele...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 1934 by cont...@vaidabogdan.com: WebDriver is not deleting the
profile directory after test exits
http://code.google.com/p/selenium/issues/detail?id=1934

What steps will reproduce the problem?
1. On running RemoteWebDriver with an instantiated FirefoxProfile it
creates 2 directories: anonymous* and webdriver*(some random number) in
“C:\Documents and Settings\<UserName>\Local Settings\Temp”. The directory
webdriver* (of ~2200K) is not removed after WebDriver finishes its job.

What is the expected output? What do you see instead?
Either it should not create the directory or it should delete it after
finishing it's job


What version of the product are you using? On what operating system?
Windows XP
Selenium 2.0rc3


Please provide any additional information below.
I am not whether it will create a problem in WebDriver however it may slow
the System performance and will unnecessary eats up the system disk space.

Also it seems related to Issue 1211
(http://code.google.com/p/selenium/issues/detail?id=1211).

[sele...@googlecode.com]

Updates:
Status: NeedsClarification

Comment #1 on issue 1934 by james.h....@gmail.com: WebDriver is not

deleting the profile directory after test exits
http://code.google.com/p/selenium/issues/detail?id=1934

Which language binding? The temp file creation and deletion is handled
differently by the different language bindings, so knowing which language
you're using is important in this case.

[sele...@googlecode.com]

Comment #2 on issue 1934 by cont...@vaidabogdan.com: WebDriver is not

deleting the profile directory after test exits
http://code.google.com/p/selenium/issues/detail?id=1934

I use Java for the development.

[sele...@googlecode.com]

Comment #3 on issue 1934 by wantash...@gmail.com: WebDriver is not deleting

the profile directory after test exits
http://code.google.com/p/selenium/issues/detail?id=1934

My experience is the same while setup combo is win7/webdriver 2.0rc3/java.
Can it affect performance of the regression run?

[sele...@googlecode.com]

Comment #4 on issue 1934 by barancev: WebDriver is not deleting the profile

directory after test exits
http://code.google.com/p/selenium/issues/detail?id=1934

A patch is attached that fixes this issue.

Attachments:
FirefoxProfile.patch 573 bytes

[sele...@googlecode.com]

Updates:
Cc: francois.reynaud

Comment #5 on issue 1934 by francois.reynaud: WebDriver is not deleting the

profile directory after test exits
http://code.google.com/p/selenium/issues/detail?id=1934

(No comment was entered for this change.)

[sele...@googlecode.com]

Comment #6 on issue 1934 by simon.m.stewart: WebDriver is not deleting the

profile directory after test exits
http://code.google.com/p/selenium/issues/detail?id=1934

I'm not entirely sure how this fixes the issue: the "dir" being deleted is
already marked as a temporary filesystem and should be deleted when the jvm
exits. Deleting the temporary directory before the FirefoxProfile is
actually discarded will cause some stability problems too.

Am I missing something very obvious?

[sele...@googlecode.com]

Comment #7 on issue 1934 by francois.reynaud: WebDriver is not deleting the

profile directory after test exits
http://code.google.com/p/selenium/issues/detail?id=1934

i think the problem is for long running server in grid for instance.

[sele...@googlecode.com]

Comment #8 on issue 1934 by barancev: WebDriver is not deleting the profile

directory after test exits
http://code.google.com/p/selenium/issues/detail?id=1934

1. Yes, Francois is right, for a long running server (especially a virtual
machine with a small disk) it is a problem. Each profile can be several
megabytes in size if some FF plugins are used (e.g. firebug is about 2MB),
several hundreds of tests causes "low disk space" situation.

2. Actually, dir is a temporary directory that contains a profile extracted
from json string, but FirefoxProfile(dir) constructor copies content of
this directory (webdriver*) to a new profile directory (anonymous*), and
immediately after copying dir can be safely removed. So, I think there is
no need to wait until exit.

[sele...@googlecode.com]

Comment #9 on issue 1934 by Talwinde...@gmail.com: WebDriver is not

deleting the profile directory after test exits
http://code.google.com/p/selenium/issues/detail?id=1934

Any Updates on this issue, as i am doing evaluation of the framework to
adopt it in my team. each time i run a script it creates 19MB file in temp
directory which can be disastrous for system running multiple test cases.

[sele...@googlecode.com]

Comment #10 on issue 1934 by peterkwa...@gmail.com: WebDriver is not

deleting the profile directory after test exits
http://code.google.com/p/selenium/issues/detail?id=1934

I have encountered this issue as well. My long-running Selenium server,
running on a small VM with 8 GB of diskapce, is running out of diskspace
due to temporary files under /tmp.

I noticed that these files are cleaned up on JVM exit (probably because of
the tmp file status). However, for long-running server, this represents a
leak, since the JVM would not be restarted often.

Also interesting to note that I don't seem to have the same problem on
Windows, only on Linux do I see thousands of leaked profile directories
(although my Linux usage is a lot heavier, so this may not be a valid
observation).

[sele...@googlecode.com]

Comment #11 on issue 1934 by n...@perfectmarket.com: WebDriver is not

deleting the profile directory after test exits
http://code.google.com/p/selenium/issues/detail?id=1934

I'm observing the same issue on our Windows 7 VM using RemoteWebDriver,
with 12GB of temporary Firefox profile directories being generated in about
a month. There's also about a thousand empty plugtmp-* directories, a few
hundred scoped_dir* directories with ~20MB and Chrome profiles, and several
hundred webdriver*libs directories with 1MB IEdriver.dll files in them.

[sele...@googlecode.com]

Updates:
Status: Fixed

Comment #12 on issue 1934 by barancev: WebDriver is not deleting the

profile directory after test exits
http://code.google.com/p/selenium/issues/detail?id=1934

This issue was closed by revision r13935.

[sele...@googlecode.com]

Updates:
Status: New

Comment #14 on issue 1934 by kristian...@gmail.com: WebDriver is not

deleting the profile directory after test exits
http://code.google.com/p/selenium/issues/detail?id=1934

Reopened since r13935 was reverted in r13956 due to test break

[sele...@googlecode.com]

Comment #15 on issue 1934 by barancev: WebDriver is not deleting the

profile directory after test exits
http://code.google.com/p/selenium/issues/detail?id=1934

Well, may be we have to remove the profile directory when driver.quit() is
called? Will it work for Grid? I'm having out-of-disk-space on my virtual
machines almost every day :(

[sele...@googlecode.com]

Comment #16 on issue 1934 by kristian...@zenior.no: WebDriver is not

deleting the profile directory after test exits
http://code.google.com/p/selenium/issues/detail?id=1934

Quit sounds good to me, especially if the tests dont break ;)

[sele...@googlecode.com]

Comment #17 on issue 1934 by peterkwa...@gmail.com: WebDriver is not

deleting the profile directory after test exits
http://code.google.com/p/selenium/issues/detail?id=1934

In the release note for Selenium 2.8, it is claimed that this issue of
profile directory filling up disk is fixed.

As far as I can tell, it is not fixed.

At the end of my test runs on the 2.8 Selenium server, even after all test
sessions are properly closed, a bunch of directories remain in /tmp:

drwxr-xr-x 2 root root 4096 Oct 9 01:59 1318110895846/
drwxr-xr-x 2 root root 4096 Oct 9 01:59 1318110895847/
drwxr-xr-x 2 root root 4096 Oct 9 01:59 1318110895848/
drwxr-xr-x 2 root root 4096 Oct 9 01:59 1318110895849/
drwxr-xr-x 2 root root 4096 Oct 9 01:59 1318110895850/
drwxr-xr-x 2 root root 4096 Oct 9 01:59 1318110895851/
drwxr-xr-x 6 root root 4096 Oct 9 02:00
anonymous1107044062167549014webdriver-profile/
drwxr-xr-x 6 root root 4096 Oct 9 02:00
anonymous2288986081707850643webdriver-profile/
drwxr-xr-x 6 root root 4096 Oct 9 02:00
anonymous3928139591340740449webdriver-profile/
drwxr-xr-x 6 root root 4096 Oct 9 01:58
anonymous425239302836435538webdriver-profile/
drwxr-xr-x 6 root root 4096 Oct 9 01:56
anonymous5847048534096526317webdriver-profile/

The anonymous* directories are deleted only upon JVM termination for
Selenium server.

Furthermore, in the 2.8 release, I now see a new kind of leaks - the
integer based directories are not cleaned up at all.

This is after the server/JVM has terminated:

drwxr-xr-x 2 root root 4096 Oct 9 01:57 1318110895845/
drwxr-xr-x 2 root root 4096 Oct 9 01:59 1318110895846/
drwxr-xr-x 2 root root 4096 Oct 9 01:59 1318110895847/
drwxr-xr-x 2 root root 4096 Oct 9 01:59 1318110895848/
drwxr-xr-x 2 root root 4096 Oct 9 01:59 1318110895849/
drwxr-xr-x 2 root root 4096 Oct 9 01:59 1318110895850/
drwxr-xr-x 2 root root 4096 Oct 9 01:59 1318110895851/

These integer directories are empty inside.

[sele...@googlecode.com]

Updates:
Status: Fixed

Comment #18 on issue 1934 by kristian...@gmail.com: WebDriver is not

deleting the profile directory after test exits
http://code.google.com/p/selenium/issues/detail?id=1934

Fixed (again) in r14142

[sele...@googlecode.com]

Comment #19 on issue 1934 by jong...@gmail.com: WebDriver is not deleting

the profile directory after test exits
http://code.google.com/p/selenium/issues/detail?id=1934

I don't think this issue was fixed. I'm using Grid/WD version 2.11.0 and
the Grid machine dir "C:\Users\qauser\AppData\Local\Temp" is filled with
the following folders "webdriver113516513935198274duplicated" which
contains my custom FF profile. Each folder is about 12MB. After a week or
two my Grid server suffered from "low disk space" and i realized the temp
folder reached 19GB!!!
Now, i guess i can write a small script which deletes those folder every
once in a while but i think this should be fixed in WD.

BTW, i'm using Java if this info is important.

[sele...@googlecode.com]

Updates:
Status: Accepted

Comment #20 on issue 1934 by kristian...@gmail.com: WebDriver is not

deleting the profile directory after test exits
http://code.google.com/p/selenium/issues/detail?id=1934

@jongler, I think you are right, there are actually multiple issues hiding
inside this thread, and the /original/ issue is not fixed. I'm reopening,
this is for the specific leak associated with the method
FirefoxProfile#fromJson (serialized profiles on remote node)

[sele...@googlecode.com]

Comment #21 on issue 1934 by jong...@gmail.com: WebDriver is not deleting

the profile directory after test exits
http://code.google.com/p/selenium/issues/detail?id=1934

Is there any estimation on when this bug is going to be fixed?

[sele...@googlecode.com]

Comment #22 on issue 1934 by pho...@gmail.com: WebDriver is not deleting

the profile directory after test exits
http://code.google.com/p/selenium/issues/detail?id=1934

Deleting files/directories upon JVM exit is unacceptable for some
environments (Like mine). I run routine firefox tests, and I load in
Firebug -- Each anonymous profile is ~22MB. And this is a service I run,
not a one off application.

I've resorted to patching the FirefoxProfile to track it's profile
directory, and FirefoxWebDriver's close method to delete the dir from the
FirefoxProfile (if it's anonymous).

Why isn't this the natural case?

[sele...@googlecode.com]

Comment #23 on issue 1934 by blueguit...@gmail.com: WebDriver is not

deleting the profile directory after test exits
http://code.google.com/p/selenium/issues/detail?id=1934

I just downloaded the latest C# WebDriver 2.17 and I am having this issue.
I'm not happy Bob!! The cog on the wheel is broken.

[sele...@googlecode.com]

Comment #24 on issue 1934 by clayton....@integrumtech.com: WebDriver is not

deleting the profile directory after test exits
http://code.google.com/p/selenium/issues/detail?id=1934

I was having the same problem with WebDriver 2.14 and 2.18 being used
inside of some JUnit tests.

My fix was to add the following inside my tearDownAfterClass method.

@AfterClass
public static void tearDownAfterClass() throws Exception {
TemporaryFilesystem tempFS = TemporaryFilesystem.getDefaultTmpFS();
tempFS.deleteTemporaryFiles();
driver.quit();
}

Hope this helps.