Closed Bug 1752856 Opened 4 years ago Closed 3 years ago

Crash in [@ mozilla::detail::SupportCheckedUnsafePtrImpl<T>::~SupportCheckedUnsafePtrImpl | mozilla::dom::(anonymous namespace)::TopLevelWorkerFinishedRunnable::Run]

Categories

(Core :: DOM: Workers, defect, P3)

Firefox 98
Unspecified
Windows 10
defect

Tracking

()

RESOLVED FIXED
109 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox-esr102 --- disabled
firefox96 --- unaffected
firefox97 --- unaffected
firefox98 --- disabled
firefox99 --- disabled
firefox100 --- disabled
firefox101 --- disabled
firefox102 --- disabled
firefox103 --- disabled
firefox104 --- disabled
firefox107 --- disabled
firefox108 --- disabled
firefox109 + fixed

People

(Reporter: calixte, Assigned: edenchuang)

References

(Blocks 1 open bug, Regression)

Details

(4 keywords, Whiteboard: [post-critsmash-triage])

Crash Data

Attachments

(3 files, 1 obsolete file)

Maybe Fission related. (DOMFissionEnabled=1)

Crash report: https://crash-stats.mozilla.org/report/index/496d69cb-2e3c-4715-9544-eb1890220126

MOZ_CRASH Reason: MOZ_CRASH(Found dangling CheckedUnsafePtr)

Top 10 frames of crashing thread:

0 xul.dll mozilla::detail::SupportCheckedUnsafePtrImpl<mozilla::CrashOnDanglingCheckedUnsafePtr, mozilla::CheckingSupport::Enabled>::~SupportCheckedUnsafePtrImpl dom/quota/CheckedUnsafePtr.h:284
1 xul.dll mozilla::dom::`anonymous namespace'::TopLevelWorkerFinishedRunnable::Run dom/workers/WorkerPrivate.cpp:315
2 xul.dll mozilla::ThrottledEventQueue::Inner::Executor::Run xpcom/threads/ThrottledEventQueue.cpp:81
3 xul.dll mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:770
4 xul.dll mozilla::TaskController::ProcessPendingMTTask xpcom/threads/TaskController.cpp:390
5 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1195
6 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:107
7 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:324
8 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:306
9 xul.dll nsBaseAppShell::Run widget/nsBaseAppShell.cpp:137

There are 20 crashes (from 15 installations) in nightly 98 starting with buildid 20220125190421. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1744025.

[1] https://hg.mozilla.org/mozilla-central/rev?node=968efcd33efb

Flags: needinfo?(jstutte)
Has Regression Range: --- → yes
Flags: needinfo?(jstutte) → needinfo?(echuang)
Attached file Apple crash report

I encountered crashes with mozilla::dom::WorkerPrivate::~WorkerPrivate() and mozilla::dom::(anonymous namespace)::TopLevelWorkerFinishedRunnable::Run() in the stack frequently while using the Firefox Profiler on my local build on my M1 Macbook Pro. Just yesterday, I had this crash 7 times. I'm attaching the full Apple crash report.

Steps matching what I did when it happened (not sure if it'll reproduce easily) : capture a profile, and then attempt to explore it on the profiler.firefox.com front-end. It often crashed when I tried to scroll around, or show hidden threads.

I haven't encountered this on my Intel Macbook Pro.

Attached file Linux stack from gdb

I also see this crash on my Linux debug build, and it crashes frequently enough that it makes working difficult. I replaced locally the MOZ_CRASH with an NS_WARNING.

If we can't find a quick fix for this, could we at least make the error non-fatal?

Flags: needinfo?(jstutte)

If we keep the other bugs secret, so should we do here, even though it is just "potentially unsafe".

Group: core-security
Flags: needinfo?(jstutte)
Crash Signature: [@ mozilla::detail::SupportCheckedUnsafePtrImpl<T>::~SupportCheckedUnsafePtrImpl | mozilla::dom::(anonymous namespace)::TopLevelWorkerFinishedRunnable::Run] → [@ mozilla::detail::SupportCheckedUnsafePtrImpl<T>::~SupportCheckedUnsafePtrImpl | mozilla::dom::(anonymous namespace)::TopLevelWorkerFinishedRunnable::Run] [@ mozilla::detail::SupportCheckedUnsafePtrImpl<T>::~SupportCheckedUnsafePtrImpl | mozilla::dom::W…
Group: core-security → dom-core-security
Crash Signature: [@ mozilla::detail::SupportCheckedUnsafePtrImpl<T>::~SupportCheckedUnsafePtrImpl | mozilla::dom::(anonymous namespace)::TopLevelWorkerFinishedRunnable::Run] [@ mozilla::detail::SupportCheckedUnsafePtrImpl<T>::~SupportCheckedUnsafePtrImpl | → [@ mozilla::detail::SupportCheckedUnsafePtrImpl<T>::~SupportCheckedUnsafePtrImpl | mozilla::dom::(anonymous namespace)::TopLevelWorkerFinishedRunnable::Run] [@ mozilla::detail::SupportCheckedUnsafePtrImpl<T>::~SupportCheckedUnsafePtrImpl |

Jens, can we get this bug assigned? We still have 2 weeks before the release to get a patch in 98 if we can have a safe one that would either fix of mitigate the crashes. Thanks

Flags: needinfo?(jstutte)

Just to be clear, this is a diagnostic assert that will go away in late beta. It indicates a potential problem like here in bug 1752120. It might even improve once https://phabricator.services.mozilla.com/D138442 landed, but we cannot know it just from the stack trace here.

Flags: needinfo?(jstutte)
Flags: needinfo?(echuang)

Good, our last early beta is tomorrow, so I can mark it as disabled for 98, thanks.

This is not a release crash. Investigation will continue, of course, but severity is definitely lower than S2 here.

Severity: S2 → S3
Priority: -- → P3

Could this Fenix signature be related?

FYI it was also reported by Clouseau

(In reply to Gabriele Svelto [:gsvelto] from comment #9)

Could this Fenix signature be related?

I think this is a different case. It is related somehow, of course, but I suspect it to have a different root cause.

See Also: → 1766272

I found another Fenix signature that looks suspicious, could be related.

Depends on: 1789399
Assignee: nobody → echuang
Blocks: 1791978
Attachment #9302542 - Attachment is obsolete: true

Keep this bug open for tracking if new crash reports appear after patch landed.

Crash Signature: mozilla::dom::Worker::cycleCollection::Unlink] → mozilla::dom::Worker::cycleCollection::Unlink] [@ mozilla::CheckCheckedUnsafePtrs<T>::Check | mozilla::detail::SupportCheckedUnsafePtrImpl<T>::~SupportCheckedUnsafePtrImpl | RefPtr<T>::assign_assuming_AddRef | mozilla::dom::Worker::cycleCollection::Un…

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

  • Top 10 content process crashes on beta

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(echuang)
Keywords: topcrash
Duplicate of this bug: 1766272
Flags: needinfo?(echuang)

The severity field for this bug is set to S3. However, the following bug duplicate has higher severity:

:edenchuang, could you consider increasing the severity of this bug to S2?

For more information, please visit auto_nag documentation.

Flags: needinfo?(echuang)
Severity: S3 → S2
Flags: needinfo?(echuang)
Duplicate of this bug: 1791978

Copying crash signatures from duplicate bugs.

Crash Signature: mozilla::CrashOnDanglingCheckedUnsafePtr::NotifyCheckFailure ] → mozilla::CrashOnDanglingCheckedUnsafePtr::NotifyCheckFailure ] [@ mozilla::CheckCheckedUnsafePtrs<T>::Check | mozilla::detail::SupportCheckedUnsafePtrImpl<T>::~SupportCheckedUnsafePtrImpl | RefPtr<T>::assign_assuming_AddRef | mozilla::dom::(anonymous nam…
Crash Signature: mozilla::CrashOnDanglingCheckedUnsafePtr::NotifyCheckFailure ] [@ mozilla::CheckCheckedUnsafePtrs<T>::Check | mozilla::detail::SupportCheckedUnsafePtrImpl<T>::~SupportCheckedUnsafePtrImpl | RefPtr<T>::assign_assuming_AddRef | mozilla::dom::(anonymous nam… → mozilla::CrashOnDanglingCheckedUnsafePtr::NotifyCheckFailure ] [@ mozilla::CheckCheckedUnsafePtrs<T>::Check | mozilla::detail::SupportCheckedUnsafePtrImpl<T>::~SupportCheckedUnsafePtrImpl | RefPtr<T>::assign_assuming_AddRef | mozilla::dom::(anonymous na…
Duplicate of this bug: 1764974

Not seeing any Nightly crashes since this landed. Are we good here? :)

Flags: needinfo?(echuang)

I think we can close this bug according to the crash report checking result. Remove leave-open.

Ryan, could you help to close the bug? Or I can just close it directly without modifying on Tracking flags?

Flags: needinfo?(echuang) → needinfo?(ryanvm)
Keywords: leave-open

Let's see what happens with some of the early 109 betas just to be sure. Leaving the NI for now to check back.

No crashes from Beta109 - I think we're good here!

Group: dom-core-security → core-security-release
Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(ryanvm)
Resolution: --- → FIXED
Target Milestone: --- → 109 Branch
Flags: qe-verify-
Whiteboard: [post-critsmash-triage]
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: