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

Status: NEW

(Core :: General, defect)

Description

[Allen Adamson]

Attachment: 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.

Comment 1

[Release mgmt bot [:suhaib / :marco/ :calixte]]

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.

Comment 2

[Allen Adamson]

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.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

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

Comment 4

[Allen Adamson]

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.

Comment 5

[Allen Adamson]

Attachment: 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

Comment 6

[Allen Adamson]

I got a profile, not with VB but it is when Amazon starts acting up
https://share.firefox.dev/3Kh3QT2

Comment 7

[Bas Schouten (:bas.schouten)]

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?

Comment 8

[Andrew McCreight [:mccr8]]

There are about a dozen iframes with URIs starting with https://www.amazon.com/gp/video/storefront/ 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.

Comment 9

[Sylvestre Ledru [:Sylvestre]]

Paul, do you know what is happening here? thanks

Comment 10

[Gian-Carlo Pascutto [:gcp]]

FF has crashed many times

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

Comment 11

[Gian-Carlo Pascutto [:gcp]]

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?

Comment 12

[Allen Adamson]

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.

https://crash-stats.mozilla.org/report/index/fe365d20-ee3f-4254-bfa5-314fc0230220
https://crash-stats.mozilla.org/report/index/ca8fb404-3bb4-4859-8906-a0d3e0230214
https://crash-stats.mozilla.org/report/index/e4f2ac61-a45c-40b3-bbb8-164a50230213
https://crash-stats.mozilla.org/report/index/98940612-e60d-4a90-9823-430fb0230211
https://crash-stats.mozilla.org/report/index/948169b3-81f5-4084-bcee-05ade0230211
https://crash-stats.mozilla.org/report/index/79a35359-a9ed-41b9-b7ac-446720230206

Comment 13

[Gian-Carlo Pascutto [:gcp]]

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: https://hacks.mozilla.org/2022/11/improving-firefox-stability-with-this-one-weird-trick/

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

Comment 14

[Gian-Carlo Pascutto [:gcp]]

That being said, crashes like https://crash-stats.mozilla.org/report/index/fe365d20-ee3f-4254-bfa5-314fc0230220 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.

Comment 15

[Gian-Carlo Pascutto [:gcp]]

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

Comment 16

[Ray Kraesig [:rkraesig]]

(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.