Ignore `new[]` when generating signatures
Categories
(Socorro :: Signature, task)
Tracking
(Not tracked)
People
(Reporter: cpeterson, Assigned: willkg)
References
Details
Attachments
(1 file)
(deleted),
text/x-github-pull-request
|
Details |
I see a bunch of Android OOMs with the same generic crash signature: [@ OOM | large | mozalloc_abort | moz_xmalloc | new[] ]
. I think stack traces should ignore operator new[]
when generating signatures.
For example, bug 1802623's crash signature is currently [@ OOM | large | mozalloc_abort | moz_xmalloc | new[] ]
, but I think it would be more useful if it was something like [@ OOM | large | mozalloc_abort | moz_xmalloc | new[] | mozilla::SPSCRingBufferBase<short>::SPSCRingBufferBase ]
.
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
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 1•2 years ago
|
||
Assignee | ||
Comment 2•2 years ago
|
||
Assignee | ||
Comment 3•2 years ago
|
||
I pushed this just now to production in bug #1803661.
Reporter | ||
Comment 4•2 years ago
|
||
(In reply to Will Kahn-Greene [:willkg] ET needinfo? me from comment #3)
I pushed this just now to production in bug #1803661.
Thanks! I already see a few crash reports with the new crash signature for bug 1802623.
Description
•