Closed
Bug 1176837
Opened 9 years ago
Closed 5 years ago
crash in OOM | large | mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | std::allocator<T>::allocate(unsigned int)
Categories
(Core :: Graphics: CanvasWebGL, defect, P3)
Tracking
()
People
(Reporter: vtamas, Assigned: jgilbert)
References
Details
(Keywords: crash, Whiteboard: [gfx-noted])
Crash Data
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•9 years ago
|
||
This shows up in 39 beta 6 and 7. No other versions seem affected.
status-firefox39:
--- → affected
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?
Flags: needinfo?(jgilbert)
Flags: needinfo?(bgirard)
Whiteboard: [gfx-noted]
Assignee | ||
Comment 3•9 years ago
|
||
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.
Flags: needinfo?(bgirard)
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → jgilbert
Flags: needinfo?(jgilbert)
Updated•9 years ago
|
Crash Signature: [@ OOM | large | mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | std::allocator<T>::allocate(unsigned int)] → [@ OOM | large | mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | std::allocator<T>::allocate(unsigned int)]
[@ OOM | large | mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | std::allocator<T>::allocate]
Assignee | ||
Comment 4•8 years ago
|
||
I don't see this on 48+, but maybe the volume is just too low so far.
Crash Signature: [@ OOM | large | mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | std::allocator<T>::allocate(unsigned int)]
[@ OOM | large | mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | std::allocator<T>::allocate] → [@ OOM | large | mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | std::allocator<T>::allocate]
status-firefox46:
--- → wontfix
status-firefox47:
--- → affected
status-firefox-esr45:
--- → affected
Comment 5•8 years ago
|
||
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
status-firefox48:
--- → affected
Comment 6•8 years ago
|
||
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
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?
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.
status-firefox49:
--- → affected
status-firefox50:
--- → affected
status-firefox51:
--- → affected
Flags: needinfo?(jgilbert)
See Also: → 1298036
Updated•8 years ago
|
Crash Signature: [@ OOM | large | mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | std::allocator<T>::allocate] → [@ OOM | large | mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | std::allocator<T>::allocate]
[@ OOM | large | mozalloc_abort | mozalloc_handle_oom | moz_xmalloc | std::_Allocate | std::vector<T>::_Reallocate]
Updated•6 years ago
|
Priority: -- → P3
Assignee | ||
Comment 10•5 years ago
|
||
Predominately 52.9.0esr (classic extension holdouts?), with the most recent version reported of 57.
Status: NEW → RESOLVED
Closed: 5 years ago
status-firefox-esr60:
--- → unaffected
Flags: needinfo?(jgilbert)
Resolution: --- → FIXED
Updated•5 years ago
|
Resolution: FIXED → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•