Crash in [@ mozilla::MozPromise<T>::ThenValueBase::ResolveOrRejectRunnable::~ResolveOrRejectRunnable]
Categories
(Toolkit :: Startup and Profile System, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox140 | --- | wontfix |
People
(Reporter: mayankleoboy1, Assigned: mossop)
References
Details
(Keywords: crash)
Crash Data
Attachments
(2 files)
Crash report: https://crash-stats.mozilla.org/report/index/c6c7fcac-02b3-4f8c-a278-127250250423
MOZ_CRASH Reason:
MozPromise::ThenValue created from 'AsyncFlush' destroyed without being either disconnected, resolved, or rejected (dispatchRv: not dispatched)
Top 10 frames:
0 xul.dll MOZ_Crash(char const*, int, char const*) mfbt/Assertions.h:381
0 xul.dll mozilla::MozPromise<ProcessInfo, nsresult, 0>::ThenValueBase::AssertIsDead() xpcom/threads/MozPromise.h:527
1 xul.dll mozilla::MozPromise<bool, nsresult, 0>::AssertIsDead() xpcom/threads/MozPromise.h:1253
2 xul.dll mozilla::MozPromise<nsTAutoStringN<char16_t, 64>, nsresult, 0>::ThenValueBase... xpcom/threads/MozPromise.h:482
3 xul.dll mozilla::MozPromise<nsTAutoStringN<char16_t, 64>, nsresult, 0>::ThenValueBase... xpcom/threads/MozPromise.h:480
4 xul.dll mozilla::Runnable::Release() xpcom/threads/nsThreadUtils.cpp:66
4 xul.dll IdleRunnableWrapper::Release() xpcom/threads/nsThreadUtils.cpp:151
5 xul.dll mozilla::RefPtrTraits<nsIRunnable>::Release(nsIRunnable*) mfbt/RefPtr.h:49
5 xul.dll nsCOMPtr<nsIRunnable>::~nsCOMPtr() xpcom/base/nsCOMPtr.h:344
5 xul.dll mozilla::TaskQueue::Dispatch(already_AddRefed<nsIRunnable>, unsigned int) xpcom/threads/TaskQueue.h:80
Been getting this crash since the last few days... Also seeing pages randomly stop loading on Firefox while Chrome loads them perfectly. Also seeing many instances where firefox keeps on running in the background when you close it.
Reporter | ||
Comment 1•3 months ago
|
||
See also https://bugzilla.mozilla.org/show_bug.cgi?id=1824294#c17, where padenot suggested the crash is around the ToolkitProfileService.
Comment 2•3 months ago
|
||
The bug is linked to a topcrash signature, which matches the following criterion:
- Top 10 AArch64 and ARM crashes on nightly
For more information, please visit BugBot documentation.
Assignee | ||
Comment 3•3 months ago
|
||
The crash reason certainly indicates nsToolkitProfileService::AsyncFlush
however the stack ends at MOZ_CRASH
being called from MozPromise<ProcessInfo, nsresult, 0>::ThenValueBase::AssertIsDead()
which would suggest that it is this promise and I don't see anything cancelling that promise if the global goes out of scope.
Am I misunderstanding this Paul?
Reporter | ||
Comment 4•3 months ago
|
||
Comment 5•3 months ago
|
||
I think we need to add something that handles the process going away indeed.
Displaying all threads in the crash report, we can see that we're in shutdown: NS_ShutdownXPCOM
is present on the stack of the main thread.
I don't immediately see anything that listen for shutdown events here, but it's one way of solving this. A common pattern is to stash the promises on the instance (or globally if static), and reject all of them in a loop when entering shutdown.
Updated•3 months ago
|
Assignee | ||
Comment 6•3 months ago
|
||
The crash reason from bug 1962022 points to promises in the profile service, but the stacks end
in promises in nsSystemInfo. I'm not sure why this is the case but none of the promises in
nsSystemInfo are set to disconnect when their calling global goes away so this seems like a useful
improvement nonetheless. Once this lands we can watch the crash frequency to see if it ends up
resolving the bug or not.
Updated•3 months ago
|
Reporter | ||
Comment 7•3 months ago
|
||
FWIW, since i filed this bug, i have not seen this crash.
Comment 9•3 months ago
|
||
bugherder |
Assignee | ||
Comment 10•3 months ago
|
||
(In reply to Mayank Bansal from comment #7)
FWIW, since i filed this bug, i have not seen this crash.
We're still getting new reports as recently as yesterday so it's not just you. I'm going to hold this bug open and check back in a bit to see whether the crashes stop.
Updated•3 months ago
|
Comment 12•2 months ago
|
||
The bug is linked to a topcrash signature, which matches the following criterion:
- Top 20 desktop browser crashes on beta (startup)
For more information, please visit BugBot documentation.
Comment 13•2 months ago
|
||
The severity field is not set for this bug.
:mossop, could you have a look please?
For more information, please visit BugBot documentation.
Comment 14•2 months ago
|
||
Based on the topcrash criteria, the crash signature linked to this bug is not a topcrash signature anymore.
For more information, please visit BugBot documentation.
Assignee | ||
Comment 15•2 months ago
|
||
This appears likely to only occur during shutdown.
Description
•