Closed
Bug 1307031
Opened 8 years ago
Closed 8 years ago
Crash in OOM | large | NS_ABORT_OOM | nsTArray_base<T>::EnsureCapacity<T> | nsTArray_Impl<T>::AppendElement<T> | `anonymous namespace''::internal_RemoteAccumulate
Categories
(Toolkit :: Telemetry, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1304519
People
(Reporter: n.nethercote, Unassigned)
References
Details
(Keywords: crash)
Crash Data
This bug was filed from the Socorro interface and is
report bp-7949da9e-e9da-42d1-9277-c06152161003.
=============================================================
This first appeared in Nightly 20160920030429. Since then it has occurred 21 times.
It's an OOM crash, and in every occurrence I looked at, the amount of memory requested is 30,856,392,496 bytes (28.74 GB)! That's a strange number, one that's not obviously related to integer overflow. (In hex it's 0x72f2f2f30... the "2f2f2f" is a bit suspicious, but not massively so.)
I suspect bug 1218576 may be the cause, because it touched this code and at about the right time. chutten, can you please take a look?
Flags: needinfo?(chutten)
|
||
Comment 1•8 years ago
|
||
Almost certainly the same underlying cause as bug 1304519, a regression from bug 1218576 as you correctly identify.
tl;dr - there appears to be some unguarded access of an nsTArray :S
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(chutten)
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•