1176837 - crash in OOM | large | mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | std::allocator<T>::allocate(unsigned int)

Status: RESOLVED WORKSFORME

(Core :: Graphics: CanvasWebGL, defect, P3)

Description

[Vasilica Tamas, QA [:vtamas]]

This bug was filed from the Socorro interface and is 
report bp-b267ce27-44ab-4c40-9337-8a8a52150623.
=============================================================

- Ran into this on Windows 8.1 32-bit, using Firefox 39 (20150622181234)
- I do not have proper STR, but it happened during Google maps testing
- Tried several other times to reproduce it, without any luck

Comment 1

[Liz Henry (:lizzard)]

This shows up in 39 beta 6 and 7. No other versions seem affected.

Comment 2

[Milan Sreckovic [:milan] (needinfo for best results)]

It's showing up as large OOM, and new graphics changes for 39b6 seem to be bug 1167356 and bug 1171682. Neither one really look like a problem, but if I was hunting - the former could have had us not crash with its signature and proceed further where we would then OOM; the later that stopped WebGL in safe mode may not have done it in all places, so we end up in a bad state.

Jeff, anything that catches your eye as weird in the crash?

Comment 3

[Kelsey Gilbert [:jgilbert]]

This is:
http://hg.mozilla.org/mozilla-central/file/2be92aa69102/gfx/angle/src/libGLESv2/renderer/d3d/d3d11/renderer11_utils.cpp#l1032

I'm not sure what the best course of action is here, since it's an OOM in std::vector::resize(), which we've made call moz_xmalloc, which is infallible. (hence this crash)

I can make a patch.

Comment 4

[Kelsey Gilbert [:jgilbert]]

I don't see this on 48+, but maybe the volume is just too low so far.

Comment 5

[BugBot [:suhaib / :marco]]

Crash volume for signature 'OOM | large | mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | std::allocator<T>::allocate':
 - nightly (version 50): 0 crash from 2016-06-06.
 - aurora  (version 49): 0 crash from 2016-06-07.
 - beta    (version 48): 824 crashes from 2016-06-06.
 - release (version 47): 6549 crashes from 2016-05-31.
 - esr     (version 45): 1702 crashes from 2016-04-07.

Crash volume on the last weeks:
             Week N-1   Week N-2   Week N-3   Week N-4   Week N-5   Week N-6   Week N-7
 - nightly          0          0          0          0          0          0          0
 - aurora           0          0          0          0          0          0          0
 - beta           108        139         99        143        138        116         29
 - release       1033       1047        975       1007        979        844        247
 - esr            211        224        232        210        186        163        111

Affected platform: Windows

Comment 6

[Sylvestre Ledru [:Sylvestre]]

Comment #5 is pretty interesting. It seems that we only see this crash on beta or later
a few potential explanations:
* we fixed it in 49
* we don't have any one using nightly or aurora being affected (unlikely)
* a feature is only available on beta or release

Comment 7

[Milan Sreckovic [:milan] (needinfo for best results)]

We updated ANGLE in 50 (bug 1281687), which doesn't explain a clean 49, but I thought I'd mention it.  Can we see the historical data for this and if it was ever on 49, while it was still nightly?

Comment 9

[Milan Sreckovic [:milan] (needinfo for best results)]

Probably didn't go away, but just moved to bug 1298036, it's just alloc vs. realloc.  Jeff, maybe let's do that patch you mentioned.

Comment 10

[Kelsey Gilbert [:jgilbert]]

Predominately 52.9.0esr (classic extension holdouts?), with the most recent version reported of 57.