Crash in [@ mozilla::dom::TimeoutManager::RunTimeout]
Categories
(Core :: mozglue, defect, P2)
Tracking
()
People
(Reporter: sg, Unassigned)
References
Details
(Keywords: assertion, crash)
Crash Data
Crash report: https://crash-stats.mozilla.org/report/index/ad75c19b-37a2-47b9-adc0-157560201013
MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(aLastCallbackTime <= aCurrentNow)
Top 10 frames of crashing thread:
0 XUL mozilla::dom::TimeoutManager::RunTimeout dom/base/TimeoutManager.cpp:940
1 XUL mozilla::dom::TimeoutExecutor::MaybeExecute dom/base/TimeoutExecutor.cpp:179
2 XUL {virtual override thunk}
3 XUL nsTimerEvent::Run xpcom/threads/TimerThread.cpp:251
4 XUL mozilla::ThrottledEventQueue::Inner::Executor::Run xpcom/threads/ThrottledEventQueue.cpp:81
5 XUL mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:515
6 XUL mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal xpcom/threads/nsThreadUtils.h:577
7 XUL nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1197
8 XUL mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:109
9 XUL MessageLoop::Run ipc/chromium/src/base/message_loop.cc:309
This seems to be happening again in Nightly since build id 20200822213808. Bug 1487778 had the same signature, but it was reported to be fixed a long time ago.
Comment 1•4 years ago
|
||
NI farre, who appears as the reviewer for this assertion.
Comment 2•4 years ago
|
||
This used to be a Windows bug but now happens for OS X as well.
For bug 1487778 this was resolved by making timestamps on Windows strictly monotonic. Re-reviewing the code for TimeoutManager::RunTimeout
I can't see another reason for this happening. That would make this a mozglue issue.
(Unfortunately Bugzilla bugs out for me when trying to change compnonent, so I can only ni :glandium, sorry for that)
Updated•4 years ago
|
Comment 3•4 years ago
|
||
The mac timestamps use mach_absolute_time, which is supposed to be monotonic... OSX didn't have clock_gettime(CLOCK_MONOTONIC)
until 10.12, so we can't really use that. We could however use it on a runtime basis... if someone wants to give a shot at this. (there's also a clock_gettime_nsec_np
for nanosecond precision)
Under the hood, clock_gettime
uses mach_boottime_usec
, but similarly, that's not available before 10.12.
Updated•4 years ago
|
Comment 4•4 years ago
|
||
This crash just happened to me for a Gmail pinned tab that was in the background with a Nightly from yesterday: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:86.0) Gecko/20100101 Firefox/86.0 ID:20201223092736
Here the crash report: bp-1f2d4b22-c0d2-48cd-9280-67bec0201224
Comment 5•4 years ago
|
||
I've had this a couple of times in the past couple of days as well. It seems to happen when coming back from suspend.
Comment 6•4 years ago
|
||
Tons of crashes on nightly for mac since build 20201223092736 (but no crashes yet in yesterday's build). Changelog https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f725a528bb4cdee5eb7e7d019fd347a840065134&tochange=d6081a1bef2d2fc5008c9c023efdf52532b4b51d
Comment 7•4 years ago
|
||
Changing the priority to p2 as the bug is tracked by a release manager for the current nightly.
See What Do You Triage for more information
Comment 8•4 years ago
|
||
This is a MOZ_DIAGNOSTIC_ASSERT
that happens here for interval timers:
https://searchfox.org/mozilla-central/source/dom/base/TimeoutManager.cpp#1003
MOZ_DIAGNOSTIC_ASSERT(aLastCallbackTime <= aCurrentNow);
The values as passed are coming from:
TimeStamp lastCallbackTime = now;
now = TimeStamp::Now();
That means the current timestamp is lower then the one as taken the last time. Even with a timer set to 0ms this shouldn't happen, right?
Updated•4 years ago
|
Comment 9•4 years ago
|
||
The recent spike has most likely been caused by the landing of Mike's patch on bug 1681445. Given that this got backed-out the number of crashes should hopefully drop with the Nightly build from yesterday.
Updated•4 years ago
|
Comment 10•4 years ago
|
||
Crashes have dropped over the last 10 days, no need to track for 86 anymore.
Updated•4 years ago
|
Description
•