1802623 - Android Crash in [@ OOM | large | mozalloc_abort | moz_xmalloc | new[]] | mozilla::SPSCRingBufferBase<T>::SPSCRingBufferBase

Status: RESOLVED WORKSFORME

(Core :: Audio/Video: Playback, defect)

Description

[Chris Peterson [:cpeterson]]

@ Paul: I see many Android crash reports about OOMs in SPSCRingBufferBase, like Windows OOM bug 1757618. The OOM Allocation Size is always exactly 2,735,304,706 bytes (2.74 GB).

Crash report: https://crash-stats.mozilla.org/report/index/52df7903-2585-4bd2-8b9d-c56090221124

Reason: SIGSEGV / SEGV_MAPERR

Top 10 frames of crashing thread:

0  libmozglue.so  MOZ_Crash  mfbt/Assertions.h:261
0  libmozglue.so  mozalloc_abort  memory/mozalloc/mozalloc_abort.cpp:35
1  libmozglue.so  mozalloc_handle_oom  memory/mozalloc/mozalloc_oom.cpp:51
2  libmozglue.so  moz_xmalloc  memory/mozalloc/mozalloc.cpp:54
3  libxul.so  operator new[]  memory/mozalloc/cxxalloc.h:42
3  libxul.so  std::__ndk1::make_unique<short []>  /builds/worker/fetches/android-ndk/sources/cxx-stl/llvm-libc++/include/memory:3012
3  libxul.so  mozilla::SPSCRingBufferBase<short>::SPSCRingBufferBase  mfbt/SPSCQueue.h:114
3  libxul.so  mozilla::MakeUnique<mozilla::SPSCRingBufferBase<short>, unsigned int>  mfbt/UniquePtr.h:605
3  libxul.so  mozilla::AudioSink::AudioSink  dom/media/mediasink/AudioSink.cpp:56
4  libxul.so  mozilla::MediaDecoderStateMachine::CreateAudioSink const  dom/media/MediaDecoderStateMachine.cpp:3338

Comment 1

[Chris Peterson [:cpeterson]]

I suspect this is a new signature for an old crash. This bug's crash data graph appears to show a big regression in September, but I think that's when Socorro's stack traces started to include inlined functions.

Comment 2

[Paul Adenot (:padenot)]

See https://bugzilla.mozilla.org/show_bug.cgi?id=1778181#c4.

Comment 3

[Chris Peterson [:cpeterson]]

Bug 1802715 has been fixed, so I'm adding what I believe the new crash signature will be.

[@ OOM | large | mozalloc_abort | moz_xmalloc | new[] | mozilla::SPSCRingBufferBase<T>::SPSCRingBufferBase]

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

[Chris Peterson [:cpeterson]]

99.4% of these crashes are from 32-bit ARM. The remaining 0.6% are from 32-bit x86.

Comment 7

[Paul Adenot (:padenot)]

I'm going to add sprinkle assertions to try to find the cause, it really is unclear.

Comment 8

[Chris Peterson [:cpeterson]]

This crash's volume declined significantly after the Fenix 112 release in mid-March. There were 4000+ crash reports from 110, but only ~400 from 111.

Did a fix land in 112 or the crash signature change?

Comment 9

[Paul Adenot (:padenot)]

Chris, https://crash-stats.mozilla.org/signature/?signature=OOM%20%7C%20large%20%7C%20mozalloc_abort%20%7C%20moz_xmalloc%20%7C%20new%5B%5D%20%7C%20mozilla%3A%3ASPSCRingBufferBase%3CT%3E%3A%3ASPSCRingBufferBase&date=%3E%3D2023-02-10T12%3A32%3A00.000Z&date=%3C2023-08-10T12%3A32%3A00.000Z paints a different story.

I don't see any crashes after 111.0a1., it's all old builds. Did I botch my query or something?

Comment 10

[Chris Peterson [:cpeterson]]

(In reply to Paul Adenot (:padenot) from comment #9)

I don't see any crashes after 111.0a1., it's all old builds. Did I botch my query or something?

LGTM. I'll close this bug as WFM. Thanks for checking!