1799300 - Crash in [@ js::gc::CellWithTenuredGCPointer<T>::headerPtr]

Reporter

Description

•

3 years ago

When looking at crash reports for 106.0.5, we started looking at this new-looking signature in 106. Given the appearance on 102.4esr as well, there was some question as to whether this might be a new signature from bug 1791363. Otherwise, is this a morphing of bug 1793644 with the top frames now being ignored by Socorro?

If it is in fact the latter, it would be good if we could start properly associating these newer signatures with that bug to avoid such confusion down the road.

Crash report: https://crash-stats.mozilla.org/report/index/065a4b0c-75e9-402f-a165-448210221105

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0  xul.dll  std::_Load_relaxed_8  /builds/worker/fetches/vs/vc/tools/msvc/14.16.27023/include/xatomic.h:1863
0  xul.dll  std::_Atomic_load_8  /builds/worker/fetches/vs/vc/tools/msvc/14.16.27023/include/xatomic.h:1891
0  xul.dll  std::atomic_load_explicit  /builds/worker/fetches/vs/vc/tools/msvc/14.16.27023/include/xxatomic:495
0  xul.dll  std::_Atomic_ullong::load const  /builds/worker/fetches/vs/vc/tools/msvc/14.16.27023/include/xxatomic:629
0  xul.dll  mozilla::detail::IntrinsicMemoryOps<unsigned long long, mozilla::Relaxed>::load  mfbt/Atomics.h:195
0  xul.dll  mozilla::detail::AtomicBaseIncDec<unsigned long long, mozilla::Relaxed>::operator unsigned long long const  mfbt/Atomics.h:340
0  xul.dll  js::gc::CellWithTenuredGCPointer<js::gc::TenuredCell, js::BaseShape>::headerPtr const  js/src/gc/Cell.h:791
0  xul.dll  js::Shape::base const  js/src/vm/Shape.h:257
0  xul.dll  js::Shape::getObjectClass const  js/src/vm/Shape.h:365
0  xul.dll  JSObject::getClass const  js/src/vm/JSObject.h:109

BugBot [:suhaib / :marco/ :calixte]

Comment 1

•

3 years ago

The bug is linked to a topcrash signature, which matches the following criterion:

Top 10 content process crashes on release

:sdetar, could you consider increasing the severity of this top-crash bug?

For more information, please visit auto_nag documentation.

Flags: needinfo?(sdetar)

Keywords: topcrash

Jon Coppeard (:jonco)

Comment 2

•

3 years ago

(In reply to Ryan VanderMeulen [:RyanVM] from comment #0)
This doesn't look like it's related to bug 1791363.

The signature seems to cover two sources of crashes: general GC crashes caused by bad memory and module loader crashes like bug 1796666.

BugBot [:suhaib / :marco/ :calixte]

Comment 3

•

3 years ago

The bug is linked to a topcrash signature, which matches the following criteria:

Top 20 desktop browser crashes on release (startup)
Top 10 content process crashes on release

:sdetar, could you consider increasing the severity of this top-crash bug?

For more information, please visit auto_nag documentation.

Flags: needinfo?(sdetar)

Keywords: topcrash-startup

Steven DeTar [:sdetar]

Updated

•

3 years ago

Flags: needinfo?(sdetar)

Gabriele Svelto [:gsvelto]

Comment 4

•

3 years ago

Bug 1795762 should make triagers life easier. Inline support has upended a lot of signatures and we're still learning what's relevant and what's not.

Gabriele Svelto [:gsvelto]

Comment 5

•

3 years ago

(In reply to Jon Coppeard (:jonco) (PTO until 7th Nov) from comment #2)

The signature seems to cover two sources of crashes: general GC crashes caused by bad memory and module loader crashes like bug 1796666.

What frames should be ignored to tell those two crashes apart? We can add then to the irrelevant list and make the two different crashes collapse under different signature.

Jon Coppeard (:jonco)

Comment 6

•

3 years ago

(In reply to Gabriele Svelto [:gsvelto] from comment #5)
It would be everything up to but not including JSObject::nonCCWRealm (I guess we're going to ignore the atomic-related ones anyway):

std::__1::__cxx_atomic_load<T>
std::__1::__atomic_base<T>::load
mozilla::detail::IntrinsicMemoryOps<T>::load
mozilla::detail::AtomicBaseIncDec<T>::operator unsigned long
js::gc::CellWithTenuredGCPointer<T>::headerPtr
JSObject::shape
JSObject::nonCCWRealm 
``

Daniel Veditz [:dveditz]

Comment 7

•

3 years ago

This does indicate generally some kind of memory screw up, but it's not actionable as a security bug and might as well be public.

Group: javascript-core-security

Bryan Thrall [:bthrall]

Comment 8

•

3 years ago

:jonco is this actionable?

Blocks: sm-defects-crashes

Flags: needinfo?(jcoppeard)

Jon Coppeard (:jonco)

Comment 9

•

3 years ago

(In reply to Bryan Thrall [:bthrall] from comment #8)

:jonco is this actionable?

No, this signature is too general and this bucket of crashes includes several different ones, some of which are likely to be caused by bad RAM.

Flags: needinfo?(jcoppeard)

Gabriele Svelto [:gsvelto]

Comment 10

•

3 years ago

(In reply to Jon Coppeard (:jonco) from comment #6)

It would be everything up to but not including JSObject::nonCCWRealm (I guess we're going to ignore the atomic-related ones anyway):
std::__1::__cxx_atomic_load<T>
std::__1::__atomic_base<T>::load
mozilla::detail::IntrinsicMemoryOps<T>::load
mozilla::detail::AtomicBaseIncDec<T>::operator unsigned long
js::gc::CellWithTenuredGCPointer<T>::headerPtr
JSObject::shape
JSObject::nonCCWRealm 
``

We're already ignoring mozilla::detail::IntrinsicMemoryOps<> and I've filed bug 1801603 to ignore the others too.

Gabriele Svelto [:gsvelto]

Updated

•

3 years ago

Depends on: 1801603

Gabriele Svelto [:gsvelto]

Comment 11

•

3 years ago

Small correction, we're also ignoring everything starting with mozilla::detail::Atomic and std::__ so we only need to get rid of the JSObject functions.

BugBot [:suhaib / :marco/ :calixte]

Comment 12

•

3 years ago

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(sdetar)

Steven DeTar [:sdetar]

Updated

•

3 years ago

Flags: needinfo?(sdetar)

BugBot [:suhaib / :marco/ :calixte]

Comment 13

•

3 years ago

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(sdetar)

Jan de Mooij [:jandem]

Updated

•

3 years ago

Duplicate of this bug: 1800984

BugBot [:suhaib / :marco/ :calixte]

Comment 15

•

3 years ago

Copying crash signatures from duplicate bugs.

Crash Signature: [@ js::gc::CellWithTenuredGCPointer<T>::headerPtr] → [@ js::gc::CellWithTenuredGCPointer<T>::headerPtr] [@ js::gc::HeaderWord::get]

Steven DeTar [:sdetar]

Updated

•

3 years ago

Crash Signature: [@ js::gc::CellWithTenuredGCPointer<T>::headerPtr] [@ js::gc::HeaderWord::get] → [@ js::gc::CellWithTenuredGCPointer<T>::headerPtr] [@ js::gc::HeaderWord::get]

Flags: needinfo?(sdetar)

BugBot [:suhaib / :marco/ :calixte]

Comment 16

•

3 years ago

The following field has been copied from a duplicate bug:

Field	Value	Source
Regressed by	bug 1798284	bug 1800984

For more information, please visit auto_nag documentation.

Keywords: regression

Regressed by: 1798284

Jan de Mooij [:jandem]

Updated

•

3 years ago

No longer regressed by: 1798284

BugBot [:suhaib / :marco/ :calixte]

Comment 17

•

3 years ago

Based on the topcrash criteria, the crash signatures linked to this bug are not in the topcrash signatures anymore.

For more information, please visit auto_nag documentation.

Keywords: topcrash-startup

BugBot [:suhaib / :marco/ :calixte]

Comment 18

•

3 years ago

The bug is linked to a topcrash signature, which matches the following criteria:

Top 20 desktop browser crashes on beta (startup)
Top 10 content process crashes on beta

:sdetar, could you consider increasing the severity of this top-crash bug?

For more information, please visit auto_nag documentation.

Flags: needinfo?(sdetar)

Keywords: topcrash-startup

Steven DeTar [:sdetar]

Updated

•

3 years ago

Flags: needinfo?(sdetar)

Nicolas B. Pierron [:nbp]

Comment 19

•

3 years ago

Based on comment 9, this is most likely a hardware issue.
Unless we have a meta-bug to inform users about bad hardware, I will simply mark this bug as stalled and block Bug 1793648 (sm-defects-hardware).

Blocks: sm-defects-hardware
No longer blocks: sm-defects-crashes

Severity: -- → S4

Keywords: stalled

Priority: -- → P5

Nicolas B. Pierron [:nbp]

The three failues in CI are all coming through this stack which includes the profiler:

[task 2024-09-20T15:33:19.219Z] 15:33:19     INFO - GECKO(19304) | #01: JSObject::nonCCWRealm() const [js/src/vm/JSObject.h:421]
[task 2024-09-20T15:33:19.223Z] 15:33:19     INFO - GECKO(19304) | #02: js::jit::JitcodeGlobalEntry::lookupRealmID(JSRuntime*, void*) const [js/src/jit/JitcodeMap.cpp:471]
[task 2024-09-20T15:33:19.223Z] 15:33:19     INFO - GECKO(19304) | #03: std::_Function_handler<void (void*), JITFrameInfo::AddInfoForRange(unsigned long, unsigned long, JSContext*, std::function<void (std::function<void (void*)> const&)> const&)::$_0>::_M_invoke(std::_Any_data const&, void*&&) [/builds/worker/fetches/sysroot-x86_64-linux-gnu/usr/include/c++/8/bits/std_function.h:297]
[task 2024-09-20T15:33:19.224Z] 15:33:19     INFO - GECKO(19304) | #04: ProfileBuffer::AddJITInfoForRange(unsigned long, mozilla::baseprofiler::BaseProfilerThreadId, JSContext*, JITFrameInfo&, mozilla::ProgressLogger) const::$_0::operator()(std::function<void (void*)> const&) const::{lambda(mozilla::ProfileChunkedBuffer::Reader*)#1}::operator()(mozilla::ProfileChunkedBuffer::Reader*) const::{lambda(mozilla::ProfileChunkedBuffer::Reader*)#1}::operator()(mozilla::ProfileChunkedBuffer::Reader*) const [tools/profiler/core/ProfileBufferEntry.cpp:1577]
[task 2024-09-20T15:33:19.225Z] 15:33:19     INFO - GECKO(19304) | #05: ProfileBuffer::AddJITInfoForRange(unsigned long, mozilla::baseprofiler::BaseProfilerThreadId, JSContext*, JITFrameInfo&, mozilla::ProgressLogger) const::$_0::operator()(std::function<void (void*)> const&) const::{lambda(mozilla::ProfileChunkedBuffer::Reader*)#1}::operator()(mozilla::ProfileChunkedBuffer::Reader*) const [tools/profiler/core/ProfileBufferEntry.cpp:1567]
[task 2024-09-20T15:33:19.226Z] 15:33:19     INFO - GECKO(19304) | #06: std::_Function_handler<void (std::function<void (void*)> const&), ProfileBuffer::AddJITInfoForRange(unsigned long, mozilla::baseprofiler::BaseProfilerThreadId, JSContext*, JITFrameInfo&, mozilla::ProgressLogger) const::$_0>::_M_invoke(std::_Any_data const&, std::function<void (void*)> const&) [/builds/worker/fetches/sysroot-x86_64-linux-gnu/usr/include/c++/8/bits/std_function.h:297]
[task 2024-09-20T15:33:19.227Z] 15:33:19     INFO - GECKO(19304) | #07: JITFrameInfo::AddInfoForRange(unsigned long, unsigned long, JSContext*, std::function<void (std::function<void (void*)> const&)> const&) [tools/profiler/core/ProfileBufferEntry.cpp:607]
[task 2024-09-20T15:33:19.227Z] 15:33:19     INFO - GECKO(19304) | #08: ProfileBuffer::AddJITInfoForRange(unsigned long, mozilla::baseprofiler::BaseProfilerThreadId, JSContext*, JITFrameInfo&, mozilla::ProgressLogger) const [tools/profiler/core/ProfileBufferEntry.cpp:1510]
[task 2024-09-20T15:33:19.228Z] 15:33:19     INFO - GECKO(19304) | #09: ProfiledThreadData::PrepareUniqueStacks(ProfileBuffer const&, JSContext*, mozilla::FailureLatch&, ProfilerCodeAddressService*, mozilla::ProgressLogger) [tools/profiler/core/ProfiledThreadData.cpp:117]
[task 2024-09-20T15:33:19.229Z] 15:33:19     INFO - GECKO(19304) | #10: ThreadStreamingContext::ThreadStreamingContext(ProfiledThreadData&, ProfileBuffer const&, JSContext*, mozilla::FailureLatch&, ProfilerCodeAddressService*, mozilla::ProgressLogger) [tools/profiler/core/ProfiledThreadData.cpp:389]
[task 2024-09-20T15:33:19.229Z] 15:33:19     INFO - GECKO(19304) | #11: mozilla::Vector<ThreadStreamingContext, (unsigned long)0, mozilla::MallocAllocPolicy>::infallibleEmplaceBack<ProfiledThreadData&, ProfileBuffer const&, JSContext*&, mozilla::FailureLatch&, ProfilerCodeAddressService*&, mozilla::ProgressLogger>(ProfiledThreadData&, ProfileBuffer const&, JSContext*&, mozilla::FailureLatch&, ProfilerCodeAddressService*&, mozilla::ProgressLogger) [mfbt/Vector.h:805]
[task 2024-09-20T15:33:19.230Z] 15:33:19     INFO - GECKO(19304) | #12: ProcessStreamingContext::AddThreadStreamingContext(ProfiledThreadData&, ProfileBuffer const&, JSContext*, ProfilerCodeAddressService*, mozilla::ProgressLogger) [tools/profiler/core/ProfiledThreadData.cpp:450]
[task 2024-09-20T15:33:19.231Z] 15:33:19     INFO - GECKO(19304) | #13: locked_profiler_stream_json_for_this_process(PSAutoLock const&, mozilla::baseprofiler::SpliceableJSONWriter&, double, PreRecordedMetaInformation const&, bool, ProfilerCodeAddressService*, mozilla::ProgressLogger) [tools/profiler/core/platform.cpp:3786]
[task 2024-09-20T15:33:19.232Z] 15:33:19     INFO - GECKO(19304) | #14: locked_profiler_save_profile_to_file(PSAutoLock const&, char const*, PreRecordedMetaInformation const&, bool) [tools/profiler/core/platform.cpp:6407]
[task 2024-09-20T15:33:19.232Z] 15:33:19     INFO - GECKO(19304) | #15: profiler_save_profile_to_file [tools/profiler/core/platform.cpp:6441]
[task 2024-09-20T15:33:19.232Z] 15:33:19     INFO - GECKO(19304) | #16: profiler_dump_and_stop() [tools/profiler/core/platform.cpp:5781]

Steve Fink [:sfink] [:s:]

Comment 24

•

10 months ago

Further, those CI failures have:

Assertion failure: this->flags() == 0, at /builds/worker/checkouts/gecko/js/src/gc/Cell.h:776

which comes from

uint64 js::jit::JitcodeGlobalEntry::lookupRealmID(JSRuntime*, void*) const
uint64 js::jit::BaselineEntry::lookupRealmID() const
JS::Realm* js::BaseScript::realm() const
JS::Realm* js::NativeObject::realm() const
JS::Realm* JSObject::nonCCWRealm() const
js::Shape* JSObject::shape() const
PtrT* js::gc::CellWithTenuredGCPointer<BaseCell, PtrT>::headerPtr() const [with BaseCell = js::gc::Cell; PtrT = js::Shape]

calling MOZ_ASSERT(this->flags() == 0);