Closed Bug 995782 Opened 11 years ago Closed 10 years ago

Large OOM in nsUrlClassifierPrefixSet::GetPrefixes

Categories

(Toolkit :: Safe Browsing, defect)

Product:
Toolkit
Component:
Safe Browsing
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1014362

People

(Reporter: alex_mayorga, Unassigned)

Details

(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is report bp-dd63aeed-0ffd-4626-bfa8-79e302140404. ============================================================= FWIW my SO got this crash on Firefox 28.0
Crashed again today. bp-f4a6ffd3-1654-42e7-98d6-065fe2140420 20/04/2014 01:54 p.m.
Happened to me today with FF 30b5 bp-e5991689-b832-4628-8772-65b162140521
Crash Signature: [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | nsUrlClassifierPrefixSet::GetPrefixes(unsigned int*, unsigned int**)] → [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | nsUrlClassifierPrefixSet::GetPrefixes(unsigned int*, unsigned int**)] [@ OOM | large | mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xm…
Summary: crash in mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | nsUrlClassifierPrefixSet::GetPrefixes(unsigned int*, unsigned int**) → Large OOM in nsUrlClassifierPrefixSet::GetPrefixes
Looking at the stacks, https://crash-stats.mozilla.com/report/list?signature=OOM%20%7C%20large%20%7C%20mozalloc_abort%28char%20const%2A%20const%29%20%7C%20mozalloc_handle_oom%28unsigned%20int%29%20%7C%20moz_xrealloc%20%7C%20nsTArray_base%3CnsTArrayInfallibleAllocator%2C%20nsTArray_CopyWithMemutils%3E%3A%3AEnsureCapacity%28unsigned%20int%2C%20unsigned%20int%29%20%7C%20nsTArray_Impl%3Cunsigned%20int%2C%20nsTArra... with mostly 1M (1048576) or 2M (2101248) allocations is also coming from nsUrlClassifierPrefixSet::GetPrefixes. https://crash-stats.mozilla.com/report/list?signature=OOM%20%7C%20large%20%7C%20mozalloc_abort%28char%20const%2A%20const%29%20%7C%20mozalloc_handle_oom%28unsigned%20int%29%20%7C%20moz_xmalloc%20%7C%20nsUrlClassifierPrefixSet%3A%3AGetPrefixes%28unsigned%20int%2A%2C%20unsigned%20int%2A%2A%29 is mostly slightly-over-2M (2566820 or similar) allocations. If that means that this is an entirely different case than the straight 1M/2M ones, please tell me and I file a separate bug for those other ones.
Crash Signature: , unsigned int**)] [@ OOM | large | mozalloc_abort(char const*) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | nsUrlClassifierPrefixSet::GetPrefixes(unsigned int*, unsigned int**)] → , unsigned int**)] [@ OOM | large | mozalloc_abort(char const*) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | nsUrlClassifierPrefixSet::GetPrefixes(unsigned int*, unsigned int**)] [@ OOM | large | mozalloc_abort(char const* const) | mozalloc_handl…
Component: Untriaged → Phishing Protection
Product: Firefox → Toolkit
The peak memory usage of this code was already reduced in another bug, but if VM is so tight that Firefox can't allocate 2M of RAM, You're Going To Have A Bad Time Anyway. (Most likely some other part of the code, or an add-on or plugin is leaking)
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
> if VM is so tight that Firefox can't allocate 2M of RAM, You're Going To > Have A Bad Time Anyway. We are usually pretty good at surviving with no 2M blocks available (referring to contiguous regions, not total free VM). With our allocation patterns, after long uptime we can be in a situation where there are only 1MB blocks available (but lots of them). So it's still good to fix the crashes that occur at >1MB sizes. KaiRo are you still seeing these after the fix from bug 1014362? If so then it might be worth looking at this some more. It seems that fallible allocations are not appropriate in this code, but maybe there are other options. Some kind of segmented array or something?
Flags: needinfo?(kairo)
(In reply to David Major [:dmajor] from comment #5) > KaiRo are you still seeing these after the fix from bug 1014362? If so then > it might be worth looking at this some more. This only landed in 32 and we barely have any data for OOM|large on Aurora and Nightly, so I can't tell. If it is still visible in significant ranges when 32 hits beta, we'll notice and reopen this, but for now I can't give much info.
Flags: needinfo?(kairo)
You need to log in before you can comment on or make changes to this bug.