Closed Bug 1679500 Opened 5 years ago Closed 4 years ago

Firefox 84 creates thousands of `cubeb-shm-*` files in temp directory when I close RDP

Categories

(Core :: Audio/Video: cubeb, defect, P1)

Product:
Core
Component:
Audio/Video: cubeb
Version:
Firefox 84
Platform:
All
Windows
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
88 Branch
Tracking Flags:
Tracking Status
firefox-esr78 --- unaffected
firefox86 --- wontfix
firefox87 --- fixed
firefox88 --- fixed

People

(Reporter: vrubleg, Assigned: kinetik)

References

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

I am connected to a remote Windows 7 x64 machine using RDP. I run Firefox there, open youtube or some other website which uses media. Open temp directory and you will see few cubeb-shm-* files there. Don't close the browser, but disconnect from this remote session, wait for 10+ seconds, and connect back. You will see that there are already dozens of such files.

The steps are from here: https://www.reddit.com/r/firefox/comments/hnezc5/weird_cubebshm_files_in_temp_folder/

Actual results:

Once I disconnected from my PC for a night. Firefox created 70000+ of such files, until it ate all the free space on my SDD (more than 150 GB, screenshot: https://veg.by/z/2020-11-20-10-01-40-03feec4a.png).

Expected results:

These files shouldn't be created in such amounts.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Audio/Video: cubeb
Product: Firefox → Core
Flags: needinfo?(kinetik)
Assignee: nobody → kinetik
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(kinetik)

Updated to Firefox 84.0b7. The bug is still easily reproducible. Hope you also was able to reproduce it.

I've got the same issue on Windows 8 x64. The whole freespace of my HDD is filled with these temp files.
When I logged in the next morning with RDP on my remote machine Windows ask to restart because there is no freespace available. Close Firefox "fix" the issue.
It's look like this issue start with Firefox 84 Beta 5.

(In reply to Memmie Lenglet from comment #3)

I've got the same issue on Windows 8 x64. The whole freespace of my HDD is filled with these temp files.
When I logged in the next morning with RDP on my remote machine Windows ask to restart because there is no freespace available. Close Firefox "fix" the issue.
It's look like this issue start with Firefox 84 Beta 5.

Do not take into consideration my latest statement, since the first 84 beta version (4) was installed on my machine only one day before the beta 5. So it could come from the first 84 beta too

Severity: -- → S3
Priority: -- → P1

Bug 1680703 is a report of similar issues beginning 83 without RDP.

Keywords: regression

i have the same issue with win8/firefox v83. and the issue seemed to have started since the firefox upgrade 2 weeks ago. i created a ticket but it was closed for duplicated reason. i guess the firefox development community created latest versions recently and released in a hurry for some reason.

i think the development team whoever came up with v83/84 can easily figure out the location of the logic where these files are getting created. it shouldnt take this long unless firefox wants these files desperately and want to drag the bug resolution. like put in my ticket, let firefox technical development team be seniors than clueless amateur juniors (who deserve support roles first). otherwise this is what happens as per our own IT experience.

one pathetic part of this issue is the files cannot be opened to see what is getting collected inside. and the latest part is, when these files created last time about 3hrs ago. i keep deleting them now manually but weird that the same old files coming back even after i delete them again and again. where it is actually stored is a big question so it keeps coming back to temp folder even we delete them.

worst case, please revoke the changes in the latest versions or better recall v83/v84 which are creating these absurd huge background files for no user specific reason. we users survived without these files for so many and why now?

A fix will be available shortly. There is no data stored in the files or ever written to disk via these files, they are used to create a temporary shared memory segment for communication between the audio client in each child process and the audio server in the parent process.

As a temporary workaround, you can disable the audio sandboxing feature by setting media.cubeb.sandbox in about:config to false. You'll need revert the preference to the default value once a fix is available to restore full functionality.

85.0b1 and the bug is not fixed.
84 was released today and as far as I understand, it also should have this bug. I'm surprised, I thought that this bug should be a blocker. These days a lot of people work remotely (because of the virus), and leaving a browser open when you disconnect from your work machine is a usual thing to do this year.

(In reply to Matthew Gregan [:kinetik] from comment #8)

A fix will be available shortly. There is no data stored in the files or ever written to disk via these files, they are used to create a temporary shared memory segment for communication between the audio client in each child process and the audio server in the parent process.

As a temporary workaround, you can disable the audio sandboxing feature by setting media.cubeb.sandbox in about:config to false. You'll need revert the preference to the default value once a fix is available to restore full functionality.

How do you do the fix around for multiple users on the same machine? example in a Citrix environment. I would like to have the temp fix automatically set the media.cubeb.sandobx to False for all users logging into the RDP.

Currently this is killing our Citrix servers with the temp profiles filling up the drives.

(In reply to Al from comment #10)

How do you do the fix around for multiple users on the same machine? example in a Citrix environment. I would like to have the temp fix automatically set the media.cubeb.sandobx to False for all users logging into the RDP.

Currently this is killing our Citrix servers with the temp profiles filling up the drives.

Do you have AutoConfig set up? This filled up my RDP server this morning but fortunately I was already set up with a centralized AutoConfig and just pushed the setting out that way:

https://support.mozilla.org/en-US/kb/customizing-firefox-using-autoconfig

Another option is group policy, since it looks like you can add any media. property to Preferences:

https://github.com/mozilla/policy-templates/blob/master/README.md#preferences

(In reply to Greg Valure from comment #11)

(In reply to Al from comment #10)

How do you do the fix around for multiple users on the same machine? example in a Citrix environment. I would like to have the temp fix automatically set the media.cubeb.sandobx to False for all users logging into the RDP.

Currently this is killing our Citrix servers with the temp profiles filling up the drives.

Do you have AutoConfig set up? This filled up my RDP server this morning but fortunately I was already set up with a centralized AutoConfig and just pushed the setting out that way:

https://support.mozilla.org/en-US/kb/customizing-firefox-using-autoconfig

Another option is group policy, since it looks like you can add any media. property to Preferences:

https://github.com/mozilla/policy-templates/blob/master/README.md#preferences

Thank you very much for the help and tips. I will take a look so see which is the best option for us. Have a great day.

Hopefully Firefox fixes this issue soon.

I can confirm that this is still an issue on Windows 10. As long as it's an issue, couldn't there be an update to default the cubeb setting to false? I can't imagine everyone using firefox wants to track down why their hard drive fills up every day. It took me 3 days to figure out that Firefox was the one wasting my C: drive...

I am desperately looking for the correct syntax to set media.cubeb.sandbox to false via a gpo.

I set the policy ComputerConfiguration -> Policies -> AdministrativeTemplates -> Mozilla -> Firefox -> Preferences
like this:

Software\Policies\Mozilla\Firefox\Preferences (REG_MULTI_SZ) =
{
"media.cubeb.sandbox": {
"Value": false,
"Status": "locked"
}
}

but still in about:config it is set to true.
What am I doing wrong? Could someone point me in the right direction? I couldn't find any documentation about what JSON-code exactly to use in the gpo to set Firefox preferences.

Thanks a lot!

(In reply to hubo from comment #14)

I am desperately looking for the correct syntax to set media.cubeb.sandbox to false via a gpo.

I set the policy ComputerConfiguration -> Policies -> AdministrativeTemplates -> Mozilla -> Firefox -> Preferences
like this:
Can't help here. However, we use the https://support.mozilla.org/en-US/kb/customizing-firefox-using-autoconfig approach. If you have one a few servers, this work very well.

Worked very well! Thank you! :-)

Thank you very much Greg Valure and every one else I was able to use the Customizing Firefox Using AutoConfig to do a temp fix.

Any update on this. I am also seeing same problem with Firefox version 84.

Updated Firefox a couple days ago and now every morning I got a disk full warning with thousands of the cubeb files in the Temp! Not funny!

Same here (FF 84.0.1)

my windows 10 system volume is full! %temp% housands of the cubeb files！

Same problem.

Win 8.1 Pro x64 + RDP, FF v84.0.2 x64.

Firefox 86b1 has been released. The bug is still with us =(

I'm preparing a fix for this now. Testing so far looks promising. If anyone would like to test an experimental build containing the potential fix, please try this Nightly build: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Nv-PGCdYTQK_u4VQ_ELVjg/runs/0/artifacts/public/build/target.zip - any feedback is appreciated.

Tested it a bit. It doesn't creates cubeb-shm-* files in %TEMP% at all. Was directory of these files changed? Or they are not used at all now?

Looking forward to when it is released in current beta channel. Hope that there are no other resource leaks when the browser stays open after RDP connection is closed.

Thanks for testing. I've switched the Windows code to a new API where temporary files are no longer required or used.

You've switched the Windows code to a new API? What does that mean for those of us still experiencing this issue?

@steve.istas It means that the issue will be fixed when the updated code is released.

@kinetik will this change be merged into current Firefox 86 beta, or we'll have to wait until Firefox 87?

When will the updated code be released?

Version 85.0.1 was released on Friday, but I see no mention of this bug in the release notes. Was it fixed in this release?

It is not fixed in the 85.0.1.

(In reply to Evgeny from comment #31)

It is not fixed in the 85.0.1.

Thank you for the response.

85.0.2 doesn't show this being fixed either. I have a lot of Citrix users wanting to use Firefox again.

I have exactly the same issue on our Citrix servers, running 2012R2. Since i upgraded from Firefox 78 to this version 85 we have instabilities of our Servers. Disks that run full and swapfiles that grow until the maximum.

By when this will be fixed officially. What would be the version number so that we will update FF only to that version in our Production environment.

The instructions people posted for a GPO to prevent this seem to be Greek to me. The Firefox GPO settings are very strange. If anyone has step by step instructions for a GPO to stop this it would be greatly appreciated.

Matthew Gregan, please try to merge your fix before Firefox 87 goes to beta.

Firefox 87b1 has been released. Seems like it creates a few cubeb-shm files, but not thousands anymore. Have the bug been fixed? Seems like yes.

Oh no, I was wrong, it still creates thousands of such files =(
But for some reason now it seems like not 100% reproducible.

Depends on: 1694777

Anyone have a workaround for this issue? We are planning to remove Firefox from our Citrix servers and not put it back on since there is a huge delay in getting a major bug resolved.

(In reply to steve.istas from comment #40)

Anyone have a workaround for this issue? We are planning to remove Firefox from our Citrix servers and not put it back on since there is a huge delay in getting a major bug resolved.

For single server systems you can use the autoconfig approach:
https://support.mozilla.org/en-US/kb/customizing-firefox-using-autoconfig

Go to Mozilla Firefox\defaults\pref
Create autoconfig.js with
"
pref("general.config.filename", "firefox.cfg");
pref("general.config.obscure_value", 0);
"
Maybe the second line is not necessary.

Go to Mozilla Firefox
Create firefox.cfg with
"
// IMPORTANT: Start your code on the 2nd line
lockPref("media.cubeb.sandbox", false)
"

Start Firefox and check at about:config the media.cubeb.sandbox settings.

On our system this works without problems (RemoteDesktop with 20+ users, no Citrix).

(In reply to Evgeny from comment #38)

Firefox 87b1 has been released. Seems like it creates a few cubeb-shm files, but not thousands anymore. Have the bug been fixed? Seems like yes.

Fixes for this bug landed in Firefox 88 (currently Nightly) via bug 1694777.

For anyone experiencing this bug, please test a current Nightly build to confirm the bug is resolved for you.

Marking resolved as bug 1694777 has landed on Nightly.

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Severity: S3 → S2
status-firefox86: --- → affected
status-firefox87: --- → affected
status-firefox88: --- → fixed
status-firefox-esr78: --- → unaffected
OS: Unspecified → Windows
Hardware: Unspecified → All

(In reply to steve.istas from comment #40)

Anyone have a workaround for this issue? We are planning to remove Firefox from our Citrix servers and not put it back on since there is a huge delay in getting a major bug resolved.

It stopped being a problem for me once I ensured none of my FF tabs was running any media. Perhaps you could try disabling the Windows sound service?

Please consider backporting the fix to at least Firefox 87, there is still enough time for testing it before it is out of beta. The bug is here for 3 months already. Firefox 88 will be released in 3 months. So, it is 3 months more of a major bug which really bothers people much. Fixing such a major bug in so slow manner is discouraging. I'm a Firefox fan since Phoenix 0.1, and don't want to switch, but I'm afraid that some other people may consider switching to another browser because of such longstanding issues in release versions of the browser.

Target Milestone: --- → 88 Branch

Bug 1694777 has now been uplifted, marking this bug as also fixed in Firefox 87 (beta).

status-firefox87: affected → fixed

Oh, thank you very much! Will test it and write here if notice any issues.

Still broken. Any idea when a fix will be released? Its been 4 months now.

(In reply to steve.istas from comment #48)

Still broken. Any idea when a fix will be released? Its been 4 months now.

It was fixed in Firefox 87.

(In reply to Matthew Gregan [:kinetik] from comment #49)

(In reply to steve.istas from comment #48)

Still broken. Any idea when a fix will be released? Its been 4 months now.

It was fixed in Firefox 87.

Ok. When is that going to be released? I keep going to help and about with no new updates past 86.0.1. So back to my question again. When will a fix be released?

(In reply to steve.istas from comment #50)

Ok. When is that going to be released? I keep going to help and about with no new updates past 86.0.1. So back to my question again. When will a fix be released?

Firefox 87 is scheduled to be released on 2021-03-23.

I don't see this mentioned in Firefox 87 as being fixed. Anyone able to confirm? I am not putting this browser back on my Citrix servers if its just going to continue to fill up the hard drives with temp files.

It is fixed in Firefox 87. The developers just don't mention every small change in the release notes.

You need to log in before you can comment on or make changes to this bug.