Closed Bug 1374947 Opened 7 years ago Closed 7 years ago

Firefox crashes if a Twitch channel is left running overnight

Categories

(Core :: Audio/Video: Playback, defect)

53 Branch
x86
Windows 10
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 1367128

People

(Reporter: jujjyl, Unassigned)

Details

(Keywords: crash)

Crash Data

Seeing this reproduce deterministically now when testing, leaving a Twitch channel such as

https://www.twitch.tv/arcus87

open in Firefox for overnight (perhaps 16 hours between checking in), and Firefox content process is in crashed state when coming back to it.

Tested to reproduce on 3 nights in a row on Firefox 53.0.3 (32bit)

The person who owns the above channel advertises a schedule of being live 10 hours a day from Monday to Friday. The crashes were reproduced on weekday nights, when the stream was mostly running, and presumably the browser had switched to observing other "hosted" channels on Twitch when the live streams finished.

Crash reports:

https://crash-stats.mozilla.com/report/index/c0addaf6-eae8-4bd3-9d99-c0b3b1170621
https://crash-stats.mozilla.com/report/index/e519515d-bc67-4545-89ca-7b7901170620
Component: General → Audio/Video
Product: Firefox → Core
These look like virtual memory fragmentation crashes.  This should be fixed by switching to 64-bit.
(In reply to Ben Kelly [reviewing, but slowly][:bkelly] from comment #1)
> These look like virtual memory fragmentation crashes.  This should be fixed
> by switching to 64-bit.

I hope that would not be a basis to disregard this as wontfix, because 64-bit is currently not universally available, especially on Android.

How do you know that this is address space fragmentation though? The crash report says "Available Virtual Memory: 239,476,736 bytes (228.38 MB)", but is there a measure that says this is due to address space fragmentation instead of leaking? Is it not possible that Firefox was leaking memory rather than fragmenting it?

Even if this was address space fragmentation related, it would be good to have JavaScript start throwing exceptions rather than nuke the content process when the OOMs occur. Also it does not seem reasonable that one Twitch page running a video unattended would be able to trash a whole 3GB address space. That kind of behavior does seem like a bug by itself.
OOM Allocation Size 	524,288 bytes (512 KB)
Available Physical Memory 	23,263,518,720 bytes (21.67 GB)

This is a long standing issue and the best fix we have is 64-bit.  Our stub installer even offers to install 64-bit now.  You don't have to go find a different URL for it any more.

On android apps get OOM killed all the time.  The OS is designed to reload the app when you re-open it from the switcher.  Its highly unlikely our app will live long enough on android to hit a VM fragmentation OOM.
Component: Audio/Video → Audio/Video: Playback
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.