Open Bug 1671141 Opened 10 months ago Updated 4 months ago

Crash in [@ mozilla::dom::TimeoutManager::RunTimeout]


(Core :: mozglue, defect, P2)




Tracking Status
firefox-esr78 --- affected
firefox84 --- wontfix
firefox85 --- affected
firefox86 --- affected


(Reporter: sg, Unassigned)


(Blocks 1 open bug)


(Keywords: assertion, crash)

Crash Data

Crash report:

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/

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.

Severity: -- → S3
Flags: needinfo?(afarre)

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)

Flags: needinfo?(afarre) → needinfo?(mh+mozilla)
Component: DOM: Core & HTML → mozglue

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.

Flags: needinfo?(mh+mozilla)
Priority: -- → P3

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.

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

Priority: P3 → P2

This is a MOZ_DIAGNOSTIC_ASSERT that happens here for interval timers:

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?

Component: mozglue → DOM: Core & HTML
Keywords: assertion
Component: DOM: Core & HTML → mozglue

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.

See Also: → 1686434
Duplicate of this bug: 1686434
Crash Signature: [@ mozilla::dom::TimeoutManager::RunTimeout] → [@ mozilla::dom::TimeoutManager::RunTimeout] [@ XUL@0xc617ba | XUL@0xc60808 | XUL@0xc62672 | XUL@0x55df6e | XUL@0x571ba4 | XUL@0x5556d0 | XUL@0x55971b | XUL@0x564408 | XUL@0x77f9ed | XUL@0x74e02f | XUL@0x10e3e98 | XUL@0x110345f | XUL@0x1585d60 | XUL@0x74e…
You need to log in before you can comment on or make changes to this bug.