Open Bug 1809763 Opened 2 months ago Updated 12 hours ago

Seems to not play nicely with VBox, someone crashes depending on who is open first


(Core :: General, defect)

Firefox 110




(Reporter: starsaa, Unassigned, NeedInfo)



(2 files)

Attached file FF Diag.txt

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0

Steps to reproduce:

Have VBox open and then open FF or have FF open and try and open VBox, or if both happen to be able to open then use as normal and wait.

PS. I do have 24GB RAM error checked, and AMD 8 core. VBox is up to date

Actual results:

When I have FF open my VBox usually doesn't open. {Just now went to get error info from it and it crashed, memory error, I did resize FF window}. On load with FF open it gives E_FAIL ConsoleWrap. If I have VBox open and try to load FF it may load or just shutdown. If it loads it will run for a while (hours sometimes) but then I start to get tabs crashing and then FF will crash soon after. Crash reports are sent

Expected results:

VBox should open with out problems, FF should open with out problems. Both should stay running with out problems and I should be able to start them in any order.

The Bugbug bot thinks this bug should belong to the 'Core::Performance' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Performance
Product: Firefox → Core

I don't know if this would have anything to do with this issue but I noticed something and I remember it happening alot even before VB installed and still does. When I watch Amazon Video even after just 1 or 2 movies/shows, if I back out and try to goto a menu it will freeze up for upto minutes at a time. I cant get into FF troubleshooting but windows taskmanager will say anywhere from 2GB-4GB of memory used. In details it will show it between 2-3 processes and one will usually say "not responding" but its memory use keeps changing so it must be responding somehow, and its not the highest memory used processes. Of the 3 if I close one ether FF will close, Amazon tab will close and FF will respond or nothing happens. When the tab closes then FF go back to normal and I just have to reopen the tab.
Hope this helps at least some and not adds more confusion.

Could you capture a performance profile when you see issues with Amazon Video.
There is a button "upload local profile" in the profiler user interface which should give a link to share.

Flags: needinfo?(starsaa)

I was able to read an error message on the
profiler tab this time. Its said it was out of memory and couldn't
processes it! I have 24GB of memory and over 15GB was still free (of
system memory) I don't know about FF addressable memory, but many
crashes ago (about 10 min) it was upto 8GB+ according to windows
Taskmanager. I did have VB open this time as well and FF would crash as
soon as amazon video page would come up. Before that when FF was running
it wouldn't crash but VB still didn't load. But at this time after FF
has crashed many times im trying to shut down VB but it is now in a
frozen state, end processes isn't even currently working on it. I still
would like to know if there may be any temp files I may be able to
salvage from the broken profiler attempts.

Flags: needinfo?(starsaa)
Attached file memory-report.json.gz

Here is a memory dump I was able to get when the profiler wasn't able to get anything because FF kept crashing. Hope it helps some

I got a profile, not with VB but it is when Amazon starts acting up

Moving to Core:General as I'm not convinced this is a performance issue or an actual resource use issue. Nothing in either the profile or the memory report points to anything going wrong inside Firefox, fwiw. Andrew, maybe you see something here that I missed?

Component: Performance → General
Flags: needinfo?(continuation)

There are about a dozen iframes with URIs starting with which seems odd, but they don't seem to be using that much memory, so I'm not sure how that could be causing such an awful issue.

Flags: needinfo?(continuation)

Paul, do you know what is happening here? thanks

Flags: needinfo?(pbone)

FF has crashed many times

Can you go to about:crashes and link a few recent crash dumps here please?

Flags: needinfo?(starsaa)
Attachment #9317206 - Attachment mime type: application/json → application/octet-stream

The about:support is also full of memory related errors:

Failure Log
(#72) Error: wr_renderer_render: OutOfMemory
(#73) Error: wr_renderer_render: OutOfMemory
(#74) Error: RenderCompositorSWGL failed mapping default framebuffer, no dt
(#75) Error: Handling webrender error 2
(#76) Error: RenderCompositorSWGL failed mapping default framebuffer, no surf
(#77) Error: wr_renderer_render: OutOfMemory
(#78) Error: Handling webrender error 2

Given that it also affects VirtualBox, my guess is that this machine has <24GB swapfile configured, so most of those 24GB is actually unusable by Windows. Unfortunately we don't seem to mention that in about:support and if it's in the memory report, I don't see it?

The top 3 are the latest and I added a couple random from the last month. Also I tried to do a profile on the last problem from about a week ago (kinda froze) but profile wouldn't upload but I was able to DL it to my computer. I thought there was a way to attach files but don't see it. Ill try and get it here. I read about the swap file and if it is windows swap then it was set to 4GB, I have since uped it 24GB. Been busy so I haven't been able to see if it helps or not.

Flags: needinfo?(starsaa)

Some of the crashes have e.g. Available Page File 43,741,184 bytes (43.74 MB) so I'm fairly sure my bet was correct, and you'll find it way more stable when set to 24GB.

If you're curious why this is required, we wrote an article about it a few months ago:

This isn't Firefox specific, it's just how Windows works 🤷

That being said, crashes like are still suspicious. But I understand this could be a race between Windows increasing swapfile size, Firefox crashing, and our crash reporter recording the current swapfile size.

See comment 14. Does the allocation coming from Rust change anything about our OOM delay machinery?

Flags: needinfo?(rkraesig)
Flags: needinfo?(gsvelto)

(In reply to Gian-Carlo Pascutto [:gcp] from comment #15)

See comment 14. Does the allocation coming from Rust change anything about our OOM delay machinery?

No, or at least it shouldn't. We expose mozjemalloc to Rust and replace the global allocator; that'll go through the same code path as anything coming from (e.g.) C.

Flags: needinfo?(rkraesig)
Flags: needinfo?(gsvelto)
You need to log in before you can comment on or make changes to this bug.