1161242 - crash in OOM | large | mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc | nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::EnsureCapacity(unsigned int, unsigned int) | mozilla::dom::CanvasRender...

Status: RESOLVED INCOMPLETE

(Core :: Graphics: Canvas2D, defect)

Description

[u279076]

This bug was filed from the Socorro interface and is 
report bp-ef686be1-8aac-4204-802c-e52212150427.
=============================================================
0 	mozalloc.dll 	mozalloc_abort(char const* const) 	memory/mozalloc/mozalloc_abort.cpp
1 	mozalloc.dll 	mozalloc_handle_oom(unsigned int) 	memory/mozalloc/mozalloc_oom.cpp
2 	mozalloc.dll 	moz_xrealloc 	memory/mozalloc/mozalloc.cpp
3 	xul.dll 	nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::EnsureCapacity(unsigned int, unsigned int) 	xpcom/glue/nsTArray-inl.h
4 	xul.dll 	mozilla::dom::CanvasRenderingContext2D::Save() 	dom/canvas/CanvasRenderingContext2D.cpp
5 	xul.dll 	mozilla::dom::CanvasRenderingContext2DBinding::save 	obj-firefox/dom/bindings/CanvasRenderingContext2DBinding.cpp
6 		@0x6be14f4 	
=============================================================
More reports: https://crash-stats.mozilla.com/report/list?product=Firefox&signature=OOM+%7C+large+%7C+mozalloc_abort%28char+const%2A+const%29+%7C+mozalloc_handle_oom%28unsigned+int%29+%7C+moz_xrealloc+%7C+nsTArray_base%3CnsTArrayInfallibleAllocator%2C+nsTArray_CopyWithMemutils%3E%3A%3AEnsureCapacity%28unsigned+int%2C+unsigned+int%29+%7C+mozilla%3A%3Adom%3A%3ACanvasRenderingContex...

This crash currently represents 1.6% of all DOM crashes with 687 reports over the last week, it's not a topcrash yet though in release. Based on reports from the last month it looks like this started with Firefox 36. A few comments mention crashing while waiting for a file to upload and the top URL is https://www.wetransfer.com/ by a huge margin (>90%) with the second and third most URLs being vimeo.com and facebook.com respectively.

I'll do some testing to see if I can shake anything out of wetransfer.com.

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

This is an OOM crash, so either we just need to live with it or we need to make the allocation fallible if it's something large.

Comment 2

[u279076]

I think it's fair to point out that the crashes per install ratio is basically 1:1, either meaning they're only running out of memory on the first try or that they're switching a different browser.

Comment 3

[u279076]

I've been doing some testing with wetransfer.com using various file upload sizes (50MB to 2GB) but have not been able to crash yet. I'm using Firefox 37.0.2 on Windows XP in a VM with 512MB of memory. Uploading a single 2GB file in a single tab, the firefox.exe process hasn't gone over 250MB. My stress test of uploading three 2GB files in parallel while having 5 youtube videos playing causes the system to hit my page file but Firefox doesn't crash.

Florin, if your team has any time, could you do some exploratory testing to see if you can shake out steps to reproduce? It's not super high priority, just whenever you can get to it.

Kyle, how risky would it be to make large allocations fallible considering we wouldn't have a way to definitively test this internally?

Comment 4

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

It just requires someone familiar with this code to audit and make sure we return the appropriate exception to the page.

Comment 5

[Andrei Vaida [:avaida]]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #3)
> Florin, if your team has any time, could you do some exploratory testing to
> see if you can shake out steps to reproduce? It's not super high priority,
> just whenever you can get to it.

Assigning Cornel here, to look into it.

Comment 6

[Cornel Ionce [:noni] [Hubs QA]]

I've tried to reproduce this crash with WeTransfer using different scenarios (video file transfer, multiple files, single large/small file, multiple file transfers in the same time etc.) but I was unable to generate a crash.

I've tested with Firefox 37.0.2 and 38.0.1 on both Windows 7 64-bit and Windows XP 32-bit. Not even a single crash was encountered in a couple of hours.

Removing myself from the QA Contact as I could not reproduce this.

Comment 7

[u279076]

Thanks for trying, Cornel. Given this is unreproducible I suspect we'll need to just live with this, unless someone familiar with the code has any ideas.

Comment 8

[u279076]

I'm closing this bug report as we've made absolutely no progress and have no new leads to investigate. Please reopen if you're able to reproduce this crash in a current version of Firefox.