Context and Summary

As bugzilla.mozilla.org/show_bug.cgi?id=1935897#c24 explains, I experienced a segmentation fault in firefox-133.0.3-2.fc41.x86_64 due to a null pointer dereference whilst profiling NextCloud's very poorly designed "Tasks" application's web-technology GUI (wim.nl.tab.digital/apps/tasks/collections/all) with a very poorly designed WebExtension ([email protected]) enabled.

I was able to fairly consistently reproduce it, or similar, for some time, in firefox-133.0.3-2.fc41.x86_64. However, I cannot anymore, in firefox-136.0.2-1.fc41.x86_64.

I do not understand the traces, so I may be unable to usefully elaborate. Instead, I suggest that you ask those who participated in the parent thread for clarification.

Crash Traces

#c35 states the undermentioned:

The common parts of the stack traces are as follows (from lower in the stack to higher in the stack):

• DoSharedSample(bool, unsigned int, mozilla::profiler::ThreadRegistrationUnlockedReaderAndAtomicRWOnThread const&, JS::ProfilingFrameIterator::Frame*, Registers const&, unsigned long, unsigned long, ProfileBuffer&, mozilla::StackCaptureOptions)
  • ExtractJsFrames(bool, mozilla::profiler::ThreadRegistrationUnlockedReaderAndAtomicRWOnThread const&, Registers const&, ProfilerStackCollector&, JS::ProfilingFrameIterator::Frame*, StackWalkControl*) – called from DoSharedSample at searchfox.org/mozilla-central/rev/a8a00d67c6c7118f0b95cffa26740202c3b9e6f3/tools/profiler/core/platform.cpp#2976-2977.
    • JS::ProfilingFrameIterator::ProfilingFrameIterator(JSContext*, JS::ProfilingFrameIterator::RegisterState const&, mozilla::Maybe<unsigned long> const&)
      • JS::ProfilingFrameIterator::iteratorConstruct(JS::ProfilingFrameIterator::RegisterState const&)
        • js::jit::JSJitProfilingFrameIterator::JSJitProfilingFrameIterator(JSContext*, void*, void*) (most common)
          • js::jit::JSJitProfilingFrameIterator::tryInitWithPC(void*) – and then more, callees of searchfox.org/mozilla-central/rev/a8a00d67c6c7118f0b95cffa26740202c3b9e6f3/js/src/jit/JSJitFrameIter.cpp#586-606.
        • js::wasm::ProfilingFrameIterator::ProfilingFrameIterator(js::jit::JitActivation const&, JS::ProfilingFrameIterator::RegisterState const&)
          • js::wasm::ProfilingFrameIterator::initFromExitFP(js::wasm::Frame const*)

Based on this, I recommend filing a bug in Core::Gecko Profiler or Core::JavaScript Engine::JIT.

It is a summary of the undermentioned, from crash-stats.mozilla.org/report/index:

1. 7d2505a0-2c7f-47ec-96f1-a498b0241208
2. f7aed262-6857-477e-bab6-f73d30241208
3. 22b39a40-44e9-43cb-a5c0-60f750241208
4. 5d3eef02-9b63-4048-bbb6-92fbb0241211
5. cc4012bd-238c-40c9-83c7-8e99e0241211
6. ba26494d-42ab-4835-b625-5647f0241211
7. 472a2d9a-9500-498b-8714-430a80241211
8. a1937c3f-1663-4fec-b824-6a2d60241211
9. eb5e1c21-3c35-4da6-a5d2-38b830241211
10. 71684621-f53a-4025-a515-0085d0241211
11. 0baeff05-4e6b-40af-bc7c-0aaec0241211

If of use too, #c4 states that GNOME Abrt reported the trace to RedHat's Bugzilla as:

Truncated backtrace:
Thread no. 1 (7 frames)
 #0 js::ScriptWarmUpData::isJitScript at /usr/src/debug/firefox-133.0-2.fc41.x86_64/js/src/vm/JSScript.h:1251
 #1 js::BaseScript::hasJitScript at /usr/src/debug/firefox-133.0-2.fc41.x86_64/js/src/vm/JSScript.h:1585
 #2 js::BaseScript::hasIonScript at /usr/src/debug/firefox-133.0-2.fc41.x86_64/js/src/vm/JSScript-inl.h:164
 #3 js::jit::JSJitProfilingFrameIterator::tryInitWithPC at /usr/src/debug/firefox-133.0-2.fc41.x86_64/js/src/jit/JSJitFrameIter.cpp:590
 #4 js::jit::JSJitProfilingFrameIterator::JSJitProfilingFrameIterator at /usr/src/debug/firefox-133.0-2.fc41.x86_64/js/src/jit/JSJitFrameIter.cpp:532
 #5 JS::ProfilingFrameIterator::iteratorConstruct at /usr/src/debug/firefox-133.0-2.fc41.x86_64/js/src/vm/Stack.cpp:571
 #6 JS::ProfilingFrameIterator::ProfilingFrameIterator at /usr/src/debug/firefox-133.0-2.fc41.x86_64/js/src/vm/Stack.cpp:489

The Bugbug bot thinks this bug should belong to the 'Core::JavaScript Engine: JIT' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Just to make sure I understand correctly, the crashes happened in Firefox 133, but no longer happen in Firefox 136?
So there is no more issue to be fixed?
Thus we can close this bug as works-for-me?

#c2

IDK. My environment was somewhat different, and I never did know the reproduction steps beyond what I've stated. If that's not enough, I'll delegate to your discretion as triage owner on whether to close. Though, rather than WORKSFORME, probably a closure state that indicates lack of information.