Temp dir rust_mozprofile is left behind after terminating geckodriver

[vkatsikaros]

I use geckodriver 0.11.1 and Mozilla Firefox 49.0 on Ubuntu 14.04.

As root, I check if firefox/geckodriver are running and if a rust_mozprofile* dir exists. All is clear.

% pgrep -fla firefox; pgrep -fla geckodriver; ls -d /tmp/rust_mozprofile.*/
ls: cannot access /tmp/rust_mozprofile.*/: No such file or directory

I run (sorry don't know enough rust to do this in rust :P )

#!/usr/bin/perl
use strict;
use warnings;

my @command = ( '/usr/local/bin/geckodriver' );
my $pid = fork();
die 'Fork failed' if not defined $pid;
if (not $pid) {
    exec(@command) or die $!;
}
sleep(2); # wait for geckodriver to launch
print "POST /session\n";
`curl --silent -X POST localhost:4444/session --data {}`;
kill(15, $pid);

Output:

1477387918975   geckodriver INFO    Listening on 127.0.0.1:4444
POST /session
1477387920983   mozprofile::profile INFO    Using profile path /tmp/rust_mozprofile.rgB7JqF0sCrV
1477387920984   geckodriver::marionette INFO    Starting browser /usr/bin/firefox
1477387920992   geckodriver::marionette INFO    Connecting to Marionette on localhost:56883

(firefox:24715): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(firefox:24715): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed

(firefox:24715): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(firefox:24715): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed
1477387922245   Marionette  INFO    Listening on port 56883
1477387924904   Marionette  INFO    startBrowser d402baa7-845f-4680-bc96-376c0dc30a9b

In the end I check again if firefox/geckodriver are running and if a rust_mozprofile* dir exists

% pgrep -fla firefox; pgrep -fla geckodriver; ls -d /tmp/rust_mozprofile.*/
24715 /usr/lib/firefox/firefox --marionette --profile /tmp/rust_mozprofile.rgB7JqF0sCrV
/tmp/rust_mozprofile.rgB7JqF0sCrV/

I see

• a firefox still running (similar to signal termination to geckodriver leaves a firefox behind if no Delete Session command was given #291 )
• /tmp/rust_mozprofile.rgB7JqF0sCrV/, that is also printed out in geckodriver's output

Just in case:

% kill 15 24715
% pgrep -fla firefox; pgrep -fla geckodriver; ls -d /tmp/rust_mozprofile.*/
/tmp/rust_mozprofile.rgB7JqF0sCrV/

but /tmp/rust_mozprofile.rgB7JqF0sCrV/ is still there.

[jgraham]

I suspect that kill(15) is not going through the codepath that will drop the tempdir::TempDir so it doesn't get deleted. Signal handling in Rust seems to be a little difficult, so this may not be trivial (but also not impossible ofc) to fix.

[vkatsikaros]

Hm, I just noticed that firefox is being ran as /usr/lib/firefox/firefox --marionette --profile /tmp/rust_mozprofile.rgB7JqF0sCrV, so the temp profile /tmp/rust_mozprofile.* is still being used by firefox after geckodriver terminates. Could this mean that firefox must first be terminated properly by geckodriver (as in #291) for the temp dir to be clreared?

[andreastt]

We may be able to use something like the chan-signal crate to receive the handleable signals and call drop(temp_dir) explicitly. We might have to implement the Drop trait for rust_mozprofile. I’m being told by better sources that this isn’t too different to how one would handle signals in C.

[zackw]

If the feature requested in #535 gets added (caller provides an existing profile which is used), then, when that feature is in use, the profile directory must not be deleted on exit. Please keep this in mind.

[maztan]

Hello, does anyone know where in the code the profile "rust_mozprofile..." i normally deleted?

[andreastt]

It will be deleted when mozprofile::Profile::temp_dir goes out of scope (is dropped).

[maztan]

Thank you for explanation. I've been digging in the code for hours then. I am trying to implement a functionality of saving the temporary profile after FF is closed but before it is actually deleted so that the modifications to the profile can be preserved. Thanks again.

[whimboo]

@vkatsikaros the version of geckodriver you are using is barely old. Can you please re-test with 0.19.1 and a current Firefox? Thanks.

[vkatsikaros]

@whimboo you are right, the report was old. I took a quick look

my setup:

# Ubuntu 14.04.2 LTS
$ firefox --version && geckodriver --version | head -n1
Mozilla Firefox 57.0.1
geckodriver 0.19.1
$ /usr/bin/vnc4server -localhost
$ export DISPLAY=vkcloud2:1  # output from vnc4server

I tried from 2 terminals A and B

terminal_A $ geckodriver 
1512402805222	geckodriver	INFO	geckodriver 0.19.1
1512402805228	geckodriver	INFO	Listening on 127.0.0.1:4444

terminal_B $ curl --silent -X POST localhost:4444/session --data {}
{"value": {"sessionId":"fa086e86-d9dc-4176-9f5a-68bc1eb9b31d","capabilities":{"acceptInsecureCerts":false,"browserName":"firefox","browserVersion":"57.0.1","moz:accessibilityChecks":false,"moz:headless":false,"moz:processID":17563,"moz:profile":"/tmp/rust_mozprofile.RmOVB1gBOoLG","moz:webdriverClick":false,"pageLoadStrategy":"normal","platformName":"linux","platformVersion":"3.13.0-57-generic","rotatable":false,"timeouts":{"implicit":0,"pageLoad":300000,"script":30000}}}}

terminal_A:
1512402809524	mozrunner::runner	INFO	Running command: "/usr/bin/firefox" "-marionette" "-profile" "/tmp/rust_mozprofile.RmOVB1gBOoLG"
1512402810388	Marionette	INFO	Enabled via --marionette
1512402812862	Marionette	INFO	Listening on port 52262
1512402813121	Marionette	DEBUG	Register listener.js for window 2147483649
# lots of
# (/usr/lib/firefox/firefox:17633): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed
# (/usr/lib/firefox/firefox:17633): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed
# (firefox:17563): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
# //bin/dbus-launch terminated abnormally with the following error: EOF in dbus-launch reading address from bus daemon

terminal_B $ pgrep -fla firefox; pgrep -fla geckodriver; ls -d /tmp/rust_mozprofile.*/
17563 /usr/lib/firefox/firefox -marionette -profile /tmp/rust_mozprofile.RmOVB1gBOoLG
17633 /usr/lib/firefox/firefox -contentproc -childID 1 -isForBrowser -intPrefs 5:50|6:-1|18:0|28:1000|34:0|35:5|36:0|45:128|46:10000|51:0|53:400|54:1|55:0|56:0|61:0|62:120|63:120|98:2|99:1|114:5000|124:0|126:0|137:10000|162:24|163:32768|165:0|166:0|174:5|178:1048576|179:100|180:5000|182:600|183:4|184:1|193:3|206:60000| -boolPrefs 1:0|2:0|4:1|26:1|27:1|30:0|33:1|37:1|38:0|39:0|40:0|43:1|44:1|47:0|48:0|49:1|50:0|52:0|57:1|58:1|59:0|60:1|64:1|65:1|66:0|67:1|68:1|69:0|70:1|73:0|74:0|77:1|78:1|82:1|83:1|84:1|85:0|86:0|88:0|89:0|90:1|91:0|92:1|95:1|97:0|100:1|101:0|108:0|113:0|116:0|118:1|119:1|121:1|125:0|127:0|129:0|131:1|132:1|138:1|139:0|140:1|142:0|153:1|160:0|161:0|164:1|167:0|169:1|171:1|172:0|177:0|181:1|186:0|187:0|188:0|189:1|190:0|191:1|192:0|195:1|198:0|199:0|200:1|201:1|202:0|203:1|204:1|205:1|207:0|208:0|210:0|218:1|219:1|220:0|221:0|222:0| -stringPrefs 3:7;release|96:0;|141:3;1.0|158:332;  ¼½¾ǃː̷̸։֊׃״؉؊٪۔܁܂܃܄ᅟᅠ᜵           ​‎‏‐’․‧

‪‫‬‭‮ ‹›⁁⁄⁒ ⅓⅔⅕⅖⅗⅘⅙⅚⅛⅜⅝⅞⅟∕∶⎮╱⧶⧸⫻⫽⿰⿱⿲⿳⿴⿵⿶⿷⿸⿹⿺⿻　。〔〕〳゠ㅤ㈝㈞㎮㎯㏆㏟꞉︔︕︿﹝﹞．／｡ﾠ�|159:4;high| -schedulerPrefs 0001,2 -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 17563 true tab
17554 geckodriver

terminal_B $ kill -15 17554

terminal_A:
Terminated

terminal_B $ pgrep -fla firefox; pgrep -fla geckodriver; ls -d /tmp/rust_mozprofile.*/
17563 /usr/lib/firefox/firefox -marionette -profile /tmp/rust_mozprofile.RmOVB1gBOoLG
17633 /usr/lib/firefox/firefox -contentproc -childID 1 -isForBrowser -intPrefs 5:50|6:-1|18:0|28:1000|34:0|35:5|36:0|45:128|46:10000|51:0|53:400|54:1|55:0|56:0|61:0|62:120|63:120|98:2|99:1|114:5000|124:0|126:0|137:10000|162:24|163:32768|165:0|166:0|174:5|178:1048576|179:100|180:5000|182:600|183:4|184:1|193:3|206:60000| -boolPrefs 1:0|2:0|4:1|26:1|27:1|30:0|33:1|37:1|38:0|39:0|40:0|43:1|44:1|47:0|48:0|49:1|50:0|52:0|57:1|58:1|59:0|60:1|64:1|65:1|66:0|67:1|68:1|69:0|70:1|73:0|74:0|77:1|78:1|82:1|83:1|84:1|85:0|86:0|88:0|89:0|90:1|91:0|92:1|95:1|97:0|100:1|101:0|108:0|113:0|116:0|118:1|119:1|121:1|125:0|127:0|129:0|131:1|132:1|138:1|139:0|140:1|142:0|153:1|160:0|161:0|164:1|167:0|169:1|171:1|172:0|177:0|181:1|186:0|187:0|188:0|189:1|190:0|191:1|192:0|195:1|198:0|199:0|200:1|201:1|202:0|203:1|204:1|205:1|207:0|208:0|210:0|218:1|219:1|220:0|221:0|222:0| -stringPrefs 3:7;release|96:0;|141:3;1.0|158:332;  ¼½¾ǃː̷̸։֊׃״؉؊٪۔܁܂܃܄ᅟᅠ᜵           ​‎‏‐’․‧

‪‫‬‭‮ ‹›⁁⁄⁒ ⅓⅔⅕⅖⅗⅘⅙⅚⅛⅜⅝⅞⅟∕∶⎮╱⧶⧸⫻⫽⿰⿱⿲⿳⿴⿵⿶⿷⿸⿹⿺⿻　。〔〕〳゠ㅤ㈝㈞㎮㎯㏆㏟꞉︔︕︿﹝﹞．／｡ﾠ�|159:4;high| -schedulerPrefs 0001,2 -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 17563 true tab
/tmp/rust_mozprofile.RmOVB1gBOoLG/   

so it seems rust_mozprofile is still there but it makes sense a firefox instance is left behind?

Let me know if I am doing sth wrong or if I can provide more info.

[whimboo]

@vkatsikaros is your test calling driver.quit()? If not Firefox will still be running, and as such the profile will remain. I tried it locally and was not able to find any other way beside leaving out driver.quit() to reproduce it. And that is expected.

[whimboo]

@aronaks sorry, but your question is not related to this issue.

[zackw]

@aronaks Persistent profiles are #535, I think.

[maztan]

@aronax, C# code:

using OpenQA.Selenium.Firefox;
using OpenQA.Selenium.Remote;
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ConsoleApplication1
{
class SeleniumFirefoxCopyProfile : OpenQA.Selenium.Firefox.FirefoxDriver
{
public static void copyProfileFolder(FirefoxDriver firefoxDriver, String detinationDir)
{
string profileDir = ((RemoteWebDriver)firefoxDriver).Capabilities.GetCapability("moz:profile").ToString();

copyDirectory(profileDir, detinationDir);
Console.WriteLine("Copied: '" + profileDir + "' to '" + detinationDir + "'");
}

private static void copyDirectory(string Src, string Dst)
{
String[] Files;

if (Dst[Dst.Length - 1] != Path.DirectorySeparatorChar)
Dst += Path.DirectorySeparatorChar;
if (!Directory.Exists(Dst)) Directory.CreateDirectory(Dst);
Files = Directory.GetFileSystemEntries(Src);
foreach (string Element in Files)
{
try
{
// Sub directories
if (Directory.Exists(Element))
copyDirectory(Element, Dst + Path.GetFileName(Element));
// Files in directory
else
File.Copy(Element, Dst + Path.GetFileName(Element), true);
}
catch (IOException ex)
{
Console.Error.WriteLine(ex.Message);
}
}
}
}
}

usage:

FirefoxDriver driver = new FirefoxDriver();
SeleniumFirefoxCopyProfile.copyProfileFolder(driver, @"path\to\destination\dir");
driver.Quit();

[ambirag]

This issue is still happening
Geckodriver - 0.19.1
Selenium Webdriver 3.8.1
FF version: v57, Chrome v62
Setup: selenium grid
Framework: watir
OS: Ubuntu/AWS

Quit is being called at the end of browser session
Following files (hundreds of them) are being created in /tmp
tmpaddon*
rust_mozprofile.*
and within a week, it would be around 4GB in size.

[whimboo]

@ambirag would you mind attaching a trace level log when you see this problem? Make sure to clean-up the tmp directory before.

[ghost]

Is there any update on this issue? I have /tmp directories being completely filled by tmpaddon and rust_mozprofile files. Is there a workaround to at least set the temporary directory where these files are created to a different location?

[andreastt]

As per common Unix practice, you can set TMPDIR to where the program will store temporary files.

[whimboo]

I also noticed the tmpaddon files which not get removed. This is actually related to the downloaded GMP and WideVine video codecs. I wonder if we should disable the download of those video codecs. At least we would have to add a section to the readme of geckodriver what testers have to do to run tests for sites which need those codecs.

On the other side this could most likely also be a problem of Firefox, not removing those files after installing the codecs.

@aswan are you aware of that problem?

[aswan]

I'm not aware. My knowledge of GMP is limited to the front-end bits in about:addons. This is kind of a shot in the dark but perhaps somebody like cpeterson could help.

[whimboo]

Ah, I checked the code and who made most of the modifications. Looks like Chris Pearce is our man here. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1467247 to cover that.

@andreastt and @AutomatedTester beside the retention problem of the downloaded files above, I wonder if we should disable the download of those video codec plugins by default when geckodriver is in use. If someone has to test videos with those codecs the pref could be flipped, and Firefox would download and install the plug-ins. Or do you think we should keep it enabled to have it ready nearly immediately?

[andreastt]

@whimboo Sure, I think that’s a good idea. We already disable Flash and similar plugins.

[whimboo]

I will get them disabled via https://bugzilla.mozilla.org/show_bug.cgi?id=1467700, which we hopefully can still squeeze into the next geckodriver 0.21.0 release.

If anyone is still seeing that profile directories are left behind, please report again including the code in use and attach the the trace log. Thanks.

[JekRock]

Is there any way to change the folder where rust_mozprofile folders are created except changing TEPM system variable?

[andreastt]

@JekRock Assuming you mean TMPDIR. That’s the only way to configure where the temporary profile is created.

[andreastt]

I just realised TMPDIR only applies to Unix systems. On Windows systems these variables are read, in order: TMP, TEMP, USERPROFILE.

I will take a follow-up to document this on https://firefox-source-docs.mozilla.org/testing/geckodriver/.

[JekRock]

@andreastt thanks again for the pointing out on the ability to set system variable for the process here
At least it's a good workaround for the problem.

[whimboo]

@andreastt did we ever file a bug for this problem? Maybe I miss it but I cannot find anything related in the geckodriver nor mozbase rust component.

[andreastt]

I think this is related to the same problem discussed in https://bugzilla.mozilla.org/show_bug.cgi?id=1433495#c4 et seq.

The reason the temporary directory is left behind is because Rust unwinds the stack abruptly when geckodriver is interrupted by a signal. tempfile removes the folder as expected when it goes out of scope and there are no more references to it, but Drop (the destructor) isn’t called when the program is interrupted.

[ncovercash]

Still happening in 2021 on 0.28.0.

[whimboo]

Note that this issue is still blocked on #291.

[amat-git]

Any resolution on this issue? Still continues to be an issue