Closed Bug 1546186 Opened 6 years ago Closed 5 years ago

Crash in [@ OOM | large | mozalloc_abort | mozalloc_handle_oom | moz_xrealloc | nsTArray_base<T>::EnsureCapacity<T> | nsTArray_Impl<T>::AppendElement<T> | mozilla::a11y::DocAccessibleChildBase::SerializeTree]

Categories

(Core :: Disability Access APIs, defect, P3)

Unspecified
Windows
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: gsvelto, Unassigned)

Details

(Keywords: crash)

Crash Data

This bug is for crash report bp-57a33ed0-b103-4a99-8516-f408d0190417.

Top 10 frames of crashing thread:

0 mozglue.dll mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:33
1 mozglue.dll mozalloc_handle_oom memory/mozalloc/mozalloc_oom.cpp:51
2 mozglue.dll moz_xrealloc memory/mozalloc/mozalloc.cpp:90
3 xul.dll nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::EnsureCapacity<nsTArrayInfallibleAllocator> xpcom/ds/nsTArray-inl.h:191
4 xul.dll static struct CounterKeyedSample* nsTArray_Impl<CounterKeyedSample, nsTArrayInfallibleAllocator>::AppendElement<CounterKeyedSample&, nsTArrayInfallibleAllocator> xpcom/ds/nsTArray.h:2388
5 xul.dll static void mozilla::a11y::DocAccessibleChildBase::SerializeTree accessible/ipc/DocAccessibleChildBase.cpp:64
6 xul.dll static void mozilla::a11y::DocAccessibleChildBase::SerializeTree accessible/ipc/DocAccessibleChildBase.cpp:70
7 xul.dll static void mozilla::a11y::DocAccessibleChildBase::SerializeTree accessible/ipc/DocAccessibleChildBase.cpp:70
8 xul.dll static void mozilla::a11y::DocAccessibleChildBase::SerializeTree accessible/ipc/DocAccessibleChildBase.cpp:70
9 xul.dll static void mozilla::a11y::DocAccessibleChildBase::SerializeTree accessible/ipc/DocAccessibleChildBase.cpp:70

The crashes under this signatures are all valid OOM conditions (usually with the machine running low in either commit space or virtual memory) but they have two odd aspects: the first one is that they all have accessibility activated, the second one is that the allocations leading to the OOM condition tend to be rather large. With the smallest being 512KiB and the largest ones hitting almost ~100MiB.

I'm not sure if it's possible to avoid large allocations in this context so I'm filing this just to track it since I see this signature popping up from time to time.

The priority flag is not set for this bug.
:Jamie, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jteh)
Flags: needinfo?(jteh)
Priority: -- → P3

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.