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.

NI farre, who appears as the reviewer for this assertion.

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)

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.

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

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.

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

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

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?

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.

Crashes have dropped over the last 10 days, no need to track for 86 anymore.