This bug was filed from the Socorro interface and is report bp-fd819af6-954f-432f-bd1a-ade3b2150219. ============================================================= Yesterday I started experiencing extremely reliable crashes with my regular profile that I couldn't reproduce on a clean profile. Looking at the crash reports, here's the relevant stack: 0 NS_ABORT_OOM(unsigned long) xpcom/base/nsDebugImpl.cpp 1 nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::EnsureCapacity(unsigned long, unsigned long) xpcom/glue/nsTArray.h 2 nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::EnsureCapacity(unsigned long, unsigned long) xpcom/glue/nsTArray-inl.h 3 mozilla::safebrowsing::ChunkSet::Set(unsigned int) xpcom/glue/nsTArray.h 4 mozilla::safebrowsing::ProtocolParser::ProcessExpirations(nsCString const&) toolkit/components/url-classifier/HashStore.h 5 mozilla::safebrowsing::ProtocolParser::ProcessControl(bool*) toolkit/components/url-classifier/ProtocolParser.cpp 6 mozilla::safebrowsing::ProtocolParser::AppendStream(nsACString_internal const&) toolkit/components/url-classifier/ProtocolParser.cpp At a glance, it looks like we're parsing some integer values from external input that we then try to use to set the length of an nsTArray. If that value is very large, we'll obviously fail to allocate the memory and crash. More details at https://crash-stats.mozilla.com/report/index/fd819af6-954f-432f-bd1a-ade3b2150219
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1134858
You need to log in before you can comment on or make changes to this bug.