Open Bug 1483204 Opened 2 years ago Updated 2 years ago

Crash in mozilla::dom::TimeoutManager::RunTimeout


(Core :: DOM: Core & HTML, defect, P3)

Windows 7



Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- affected
firefox61 --- wontfix
firefox62 --- wontfix
firefox63 --- wontfix
firefox64 --- fix-optional


(Reporter: marcia, Assigned: farre)


(Keywords: crash, regression)

Crash Data

This bug was filed from the Socorro interface and is
report bp-de02d8ca-b4cc-4eea-8329-980a80180813.

Seen in nightly crash stats, but also in 62. Marked this one as security sensitive since it is a possible UAF: In Nightly we have 41 crashes/6 installs in the last 7 days.

As far as correlations, I noticed this: (81.25% in signature vs 06.09% overall) Addon "Ghostery – Privacy Ad Blocker" = true. No comments in any of the reports.

Top 10 frames of crashing thread:

0 xul.dll mozilla::dom::TimeoutManager::RunTimeout dom/base/TimeoutManager.cpp:698
1 xul.dll mozilla::dom::TimeoutExecutor::MaybeExecute dom/base/TimeoutExecutor.cpp:172
2 xul.dll mozilla::dom::TimeoutExecutor::Notify dom/base/TimeoutExecutor.cpp:240
3 xul.dll nsTimerImpl::Fire xpcom/threads/nsTimerImpl.cpp:704
4 xul.dll nsTimerEvent::Run xpcom/threads/TimerThread.cpp:290
5 xul.dll mozilla::ThrottledEventQueue::Inner::ExecuteRunnable xpcom/threads/ThrottledEventQueue.cpp:188
6 xul.dll mozilla::ThrottledEventQueue::Inner::Executor::Run xpcom/threads/ThrottledEventQueue.cpp:72
7 xul.dll mozilla::SchedulerGroup::Runnable::Run xpcom/threads/SchedulerGroup.cpp:337
8 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1051
9 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:519

Flags: needinfo?(afarre)
Priority: -- → P1
Haven't looked closely at this yet, but it feels fishy. TimeoutManager::mWindow is a reference, so if we have a TimeoutManager we should definitely have a window. It has been labelled as a potential startup crash, but it feels more like a shutdown crash.

I wonder if the extension mentioned creates a window to run a timeout but destroys the window while succeeding running the timeout.

I'll take this a investigate further.
Assignee: nobody → afarre
Flags: needinfo?(afarre)
It helps if you read the entire crash report. The majority of these crashes are actually a diagnostic assert in TimeoutManager::RescheduleTimeout, namely:

TimeoutManager::RescheduleTimeout(Timeout* aTimeout,
                                  const TimeStamp& aLastCallbackTime,
                                  const TimeStamp& aCurrentNow)
  MOZ_DIAGNOSTIC_ASSERT(aLastCallbackTime <= aCurrentNow);
Removing those we get a crash signature that is a bit shorter
Group: dom-core-security
No crash in 63 beta and only one crash in 64, marking as fix-optional for 63.
This is still very low volume. I'm letting it fall off the regression triage.
Very low volume, lowering the priority.
Priority: P1 → P3
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.