Closed Bug 1324875 Opened 7 years ago Closed 6 years ago

OOM when uploading large video to YouTube

Categories

(Core :: DOM: Service Workers, defect, P3)

defect

Tracking

()

RESOLVED INCOMPLETE
Tracking Status
platform-rel --- +
firefox-esr45 --- wontfix
firefox50 --- wontfix
firefox51 --- wontfix
firefox52 --- wontfix
firefox53 --- wontfix

People

(Reporter: bugzilla, Unassigned)

References

Details

(Keywords: crash, Whiteboard: [MemShrink:P1][platform-rel-Youtube])

Crash Data

This bug was filed from the Socorro interface and is 
report bp-0e11a9d9-301f-47b6-bad5-e852d2161220.
=============================================================

This looks different from bug 1141813 to me. I'm filing under Service Workers since there is service worker code on the stack, though it probably needs to be redirected.

Anyway, this is easily reproducible by a reddit user. See the thread at https://www.reddit.com/r/firefox/comments/5jc570/firefox_crashing_when_attempting_youtube_uploads/
i have seen a couple of similar reports on other support platforms today as well. maybe youtube changed something in this regard recently - can we try to do some outreach to them?
Flags: needinfo?(dchinniah)
(In reply to [:philipp] from comment #1)
> i have seen a couple of similar reports on other support platforms today as
> well. maybe youtube changed something in this regard recently - can we try
> to do some outreach to them?

If this is indeed TE related, :miktaylr? — Mike and team have the appropriate channels to reach out to the Youtube team.
platform-rel: --- → ?
Flags: needinfo?(dchinniah) → needinfo?(miket)
Whiteboard: [MemShrink] → [MemShrink][platform-rel-Youtube]
thank you, the user at https://support.mozilla.org/en-US/questions/1151172 said it started happening on 2016-12-16 for example, which would match the crash spike we see with this signature.
(In reply to [:philipp] from comment #1)
> i have seen a couple of similar reports on other support platforms today as
> well. maybe youtube changed something in this regard recently - can we try
> to do some outreach to them?

By "other support platforms" what do you mean - this is a problem on other browsers?
sorry, that should have said "support channels". the same issue with firefox was not only reported on reddit but also on support.mozilla.org & on twitter a couple of times...
Crash volume for signature 'OOM | large | NS_ABORT_OOM | nsACString_internal::SetCapacity':
 - nightly (version 53): 0 crashes from 2016-11-14.
 - aurora  (version 52): 13 crashes from 2016-11-14.
 - beta    (version 51): 223 crashes from 2016-11-14.
 - release (version 50): 2893 crashes from 2016-11-01.
 - esr     (version 45): 787 crashes from 2016-07-06.

Crash volume on the last weeks (Week N is from 01-02 to 01-08):
            W. N-1  W. N-2  W. N-3  W. N-4  W. N-5  W. N-6  W. N-7
 - nightly       0       0       0       0       0       0       0
 - aurora        0       0       2       6       0       4       0
 - beta         25      37      28      37      29      42      21
 - release     630     754     439     250     219     289     136
 - esr          25      34      32      62      42      40      28

Affected platforms: Windows, Linux

Crash rank on the last 7 days:
           Browser   Content   Plugin
 - nightly
 - aurora  #480      #1115
 - beta    #419      #529
 - release #296      #73
 - esr     #324
Asa mentioned that we are getting a lot of reports of this on Twitter, such as https://twitter.com/LastLevelPress/status/819241510495518721. Do we need any additional information to move this bug forward?
Can you retest in FF51.  I believe bug 1277681 should fix this.
Depends on: 1277681
(In reply to Ben Kelly [:bkelly] from comment #8)
> Can you retest in FF51.  I believe bug 1277681 should fix this.

Aaron any chance you can retest this?
Flags: needinfo?(aklotz)
Whiteboard: [MemShrink][platform-rel-Youtube] → [MemShrink:P1][platform-rel-Youtube]
Also, I don't believe comment 6 stats.  The 'OOM | large | NS_ABORT_OOM | nsACString_internal::SetCapacity' signature shows up for a lot of reasons.  The FF51 stacks I looked at were all from other call sites unrelated to upload streams.
I PM'd the reddit user who was experiencing this, asking them to test it out.
Flags: needinfo?(aklotz)
Flags: needinfo?(miket)
Depends on: 1330720
(In reply to Ben Kelly [:bkelly] from comment #8)
> Can you retest in FF51.  I believe bug 1277681 should fix this.

Hi Florin, would you or your team be able to help retest this in FF 51? Thank you.
Flags: needinfo?(florin.mezei)
Priority: -- → P1
I've managed to reproduce this crash on Windows 10 x86 by uploading a 5 Gb file on YouTube. (used 50.1.0
Build ID 20161208153507)

The crash is no longer reproducible on 51.0b14 (20170112171116) under Windows 10 x86/x64 and Ubuntu 16.04 x64 LTS. 

 -- Unfortunately, I can still see this issue on 2 different x86 Ubuntu LTS machines, 12.04 [1] and 16.04 [2]. However, it does not seem to have the same signature:
[1] https://crash-stats.mozilla.com/report/index/de8f7b7e-e938-4b39-8ce9-1c9272170116
[2] https://crash-stats.mozilla.com/report/index/9941a06b-11ab-4a2e-87d5-b4ae12170116

Hsin-Yi, what do you think about this results on 51.b14 running Ubuntu x86?
Flags: needinfo?(florin.mezei) → needinfo?(htsai)
Thanks for testing! According to the test results and different signature, I think we could close this bug and open news bugs for the new signatures. Any thoughts?
Flags: needinfo?(htsai)
to meantion this: even files less than 2 GB trigger the crash
(In reply to Sarah Korus from comment #16)
> to meantion this: even files less than 2 GB trigger the crash

Can you provide a link to the crash please?  You should be able to find it if you open about:crashes in a new tab.  Thanks.
Flags: needinfo?(newyijare)
(In reply to Ben Kelly [:bkelly] from comment #17)

as Mentioned in in the bug I created and Cosmin identified as duplicate of this one, the crash handler is unable to create an crash report because the App does not identify itself.
Flags: needinfo?(newyijare)
Filed bug 1333070 for Ubuntu's crash signature mentioned in comment 13.
so, another crash without the crash-handler being able to get a crash report out of it... I get this instead:
http://abload.de/image.php?img=mozillas8pac.png
I suppose the original issue was confirmed being fixed in comment 13. Without a crash report, seems it's hard for us to do anything for comment 16. Anything else we need to do to move this bug forward, or we could close this bug as fixed? Thoughts, Ben?
Flags: needinfo?(bkelly)
All I could think of doing is testing in 32-bit builds to see if this path is particularly bad for virtual memory fragmentation.  Perhaps these code paths could have some buffer re-use optimizations that would avoid heap allocations.  Thats somewhat speculative, though, and may not be possible to do.

Ultimately I think we should be moving our users to 64-bit as fast as possible to mitigate these small OOM crashes.

So I guess I'm marking as closed now.
Flags: needinfo?(bkelly)
We really need a stack from a crashing 32-bit build here. Ciprian, do you have a 32-bit system with a 32-bit build you can try reproducing this on?

Given that this is likely due to 32-bit system virtual memory fragmentation, let's wait for the correct stack and see if there's anything we can do.
Flags: needinfo?(ciprian.georgiu)
See Also: → 1333070
Note, a 32-bit build on a 64-bit system should be fine for this test.
(In reply to Andrew Overholt [:overholt] from comment #23)
> We really need a stack from a crashing 32-bit build here. Ciprian, do you
> have a 32-bit system with a 32-bit build you can try reproducing this on?

You can see below the crash link reproduced on 50.0.1 (20161123182536) with a 32-bit build.
- https://crash-stats.mozilla.com/report/index/cbde2d14-d96f-4957-9514-4fc672170222

Let me know if I can help with more info!
Flags: needinfo?(ciprian.georgiu)
(In reply to Ciprian Georgiu, QA [:ciprian_georgiu] from comment #25)
> https://crash-stats.mozilla.com/report/index/cbde2d14-d96f-4957-9514-
> 4fc672170222

Yea, virtual address fragmentation.  OOM on a 4KB allocation with 89MB free:

Total Virtual Memory 	4,294,836,224 bytes (4 GB)
Available Virtual Memory 	94,167,040 bytes (89.8 MB)
Available Page File 	3,666,042,880 bytes (3.41 GB)
Available Physical Memory 	1,207,058,432 bytes (1.12 GB)
System Memory Use Percentage 	85
OOM Allocation Size 	4,096 bytes (4 KB)
Mass wontfix for bugs affecting firefox 52.
Not sure there's much we can do here.
Priority: P1 → P3
Closing for now, we can reopen if we see this again.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.