1918742 - Crash in [@ OOM | large | NS_ABORT_OOM | nsTArray_Impl<T>::SetCapacity<T> | nsTArray_Impl<T>::nsTArray_Impl | nsTArray<T>::nsTArray | nsTArray<T>::nsTArray | mozilla::a11y::LocalAccessible::BundleFieldsForCache]

Status: NEW

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

Description

[Andrew McCreight [:mccr8]]

Crash report: https://crash-stats.mozilla.org/report/index/ee51ce1e-6ac6-46fd-92a8-9e21f0240909

MOZ_CRASH Reason: MOZ_CRASH(OOM)

Top 10 frames:

0  XUL  NS_ABORT_OOM(unsigned long)  xpcom/base/nsDebugImpl.cpp:675
1  XUL  nsTArrayInfallibleAllocator::SizeTooBig(unsigned long)  xpcom/ds/nsTArray.h:262
2  XUL  nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_RelocateUsingMemutils>::E...  xpcom/ds/nsTArray-inl.h:165
3  XUL  nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_RelocateUsingMemutils>::E...  xpcom/ds/nsTArray.h:430
3  XUL  nsTArray_Impl<int, nsTArrayInfallibleAllocator>::SetCapacity<nsTArrayInfallib...  xpcom/ds/nsTArray.h:2209
3  XUL  nsTArray_Impl<int, nsTArrayInfallibleAllocator>::nsTArray_Impl(unsigned long)  xpcom/ds/nsTArray.h:1045
3  XUL  nsTArray<int>::nsTArray(unsigned long)  xpcom/ds/nsTArray.h:2745
3  XUL  nsTArray<int>::nsTArray(unsigned long)  xpcom/ds/nsTArray.h:2745
3  XUL  mozilla::a11y::LocalAccessible::BundleFieldsForCache(unsigned long long, mozi...  accessible/generic/LocalAccessible.cpp:3721
4  XUL  mozilla::a11y::DocAccessible::ProcessQueuedCacheUpdates()  accessible/generic/DocAccessible.cpp:1541

Decent volume on this signature. MacOS only. The smallest OOM allocation size is around 2GB, so maybe there's some kind of integer under flow issue?

Comment 1

[Eitan Isaacson [:eeejay]]

Not clear how an integer underflow would be possible. This does allocate an array that is the size of the text times 4, so theoretically a node with 500,000,000 characters could do this.

Very strange that this is only MacOS.

Comment 2

[Eitan Isaacson [:eeejay]]

I'm wondering if the cpu architecture is a factor. there is an nsAutoString and nsString that are used here. Their length is a multiplier for array size. Is there any chance that an uninitialized string would return a signed/negative length?

Comment 3

[James Teh [:Jamie]]

(In reply to Eitan Isaacson [:eeejay] from comment #1)

Not clear how an integer underflow would be possible. This does allocate an array that is the size of the text times 4, so theoretically a node with 500,000,000 characters could do this.

There are several comments submitted for these crashes. Most of them suggest that the user was dealing with large plain text log or JSON files. So I think this might really be what we're dealing with.

Very strange that this is only MacOS.

Indeed. But maybe the crash signature is just different on Windows and it hasn't happened as often there for some reason? I'm trying to reproeduce this with a 500 mb text file on Windows now so I can see what the crash signature is.

Comment 4

[Andrew McCreight [:mccr8]]

I found this signature, which is on Windows: [@ OOM | large | NS_ABORT_OOM | nsTArray_Impl<T>::SetCapacity | nsTArray_Impl<T>::nsTArray_Impl | nsTArray<T>::nsTArray | mozilla::a11y::LocalAccessible::BundleFieldsForCache ]

example: bp-b7d4e533-25e4-4971-bc38-3f46b0241016

Comment 5

[James Teh [:Jamie]]

Yeah, I just reproduced it with a > 500 mb text file and got:
bp-c41a61bf-f313-436d-953f-50b720241016

Comment 6

[James Teh [:Jamie]]

Loading plain text files > 500 mb seems like a rare use case for a browser. In addition, this seems to cause layout issues as well. Dropping to s3.