Closed Bug 1810057 Opened 3 years ago Closed 2 years ago

Crash in [@ mozilla::ProfilerStringView<T>::ProfilerStringView]

Categories

(Core :: Gecko Profiler, defect, P2)

defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mccr8, Unassigned)

Details

(Keywords: crash)

Crash Data

Crash report: https://crash-stats.mozilla.org/report/index/045b7774-1728-45a9-9b20-65b9c0230111

MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(!mWhen.IsNull())

Top 10 frames of crashing thread:

0  XUL  std::__1::basic_string_view<char, std::__1::char_traits<char> >::basic_string_view  /builds/worker/fetches/MacOSX11.3.sdk/usr/include/c++/v1/string_view:230
0  XUL  std::__1::basic_string_view<char, std::__1::char_traits<char> >::basic_string_view  /builds/worker/fetches/MacOSX11.3.sdk/usr/include/c++/v1/string_view:231
0  XUL  mozilla::ProfilerStringView<char>::ProfilerStringView  mozglue/baseprofiler/public/BaseProfilerMarkersPrerequisites.h:202
0  XUL  mozilla::ProfilerStringView<char>::ProfilerStringView  mozglue/baseprofiler/public/BaseProfilerMarkersPrerequisites.h:204
0  XUL  mozilla::ProfilerStringView<char>::ProfilerStringView<  mozglue/baseprofiler/public/BaseProfilerMarkersPrerequisites.h:119
0  XUL  mozilla::dom::TimeoutManager::MoveIdleToActive  dom/base/TimeoutManager.cpp:154
0  XUL  mozilla::dom::TimeoutManager::SetLoading  dom/base/TimeoutManager.cpp:119
1  XUL  nsGlobalWindowInner::SetActiveLoadingState  dom/base/nsGlobalWindowInner.cpp:3328
2  XUL  mozilla::dom::Document::NotifyLoading  /builds/worker/fetches/MacOSX11.3.sdk/usr/include/c++/v1/atomic:1003
3  XUL  mozilla::dom::Document::SetReadyStateInternal  dom/base/Document.cpp:12062

MOZ_DIAGNOSTIC_ASSERT(!mWhen.IsNull()) is https://searchfox.org/mozilla-central/rev/893a8f062ec6144c84403fbfb0a57234418b89cf/dom/base/Timeout.cpp#72

The crash seems to be on https://searchfox.org/mozilla-central/rev/893a8f062ec6144c84403fbfb0a57234418b89cf/dom/base/TimeoutManager.cpp#154 which is:

      PROFILER_MARKER_TEXT(
          "setTimeout deferred release", DOM,
          MarkerOptions(
              MarkerTiming::Interval(
                  delta.ToMilliseconds() >= 0 ? timeout->When() : now, now),
              MarkerInnerWindowId(mWindow.WindowID())),
          marker);

This contains a ->When() call, but I'm not sure how this one could crash when the one at https://searchfox.org/mozilla-central/rev/893a8f062ec6144c84403fbfb0a57234418b89cf/dom/base/TimeoutManager.cpp#147 TimeDuration delta = now - timeout->When(); would have worked. Is it possible that the timeout object is modified from another thread?

It's also not clear to me how mozilla::ProfilerStringView<char>::ProfilerStringView< ends up on the stack if we are crashing in Timeout::When().

Flags: needinfo?(smaug)

DOM timeouts are single thread only.

Flags: needinfo?(smaug)
Severity: -- → S3
Priority: -- → P2

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.