1483204 - Crash in mozilla::dom::TimeoutManager::RunTimeout

Status: NEW

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

Description

[Marcia Knous [:marcia]]

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: https://bit.ly/2MOuWkc. 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

=============================================================

Comment 1

[Andreas Farre [:farre]]

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.

Comment 2

[Andreas Farre [:farre]]

It helps if you read the entire crash report. The majority of these crashes are actually a diagnostic assert in TimeoutManager::RescheduleTimeout, namely:

bool
TimeoutManager::RescheduleTimeout(Timeout* aTimeout,
                                  const TimeStamp& aLastCallbackTime,
                                  const TimeStamp& aCurrentNow)
{
  MOZ_DIAGNOSTIC_ASSERT(aLastCallbackTime <= aCurrentNow);
  ...

Comment 3

[Andreas Farre [:farre]]

Removing those we get a crash signature that is a bit shorter https://bit.ly/2BxxuBU.

Comment 4

[Pascal Chevrel:pascalc]

No crash in 63 beta and only one crash in 64, marking as fix-optional for 63.

Comment 5

[Liz Henry (:lizzard) (relman/hg->git project)]

This is still very low volume. I'm letting it fall off the regression triage.

Comment 6

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Very low volume, lowering the priority.

Comment 7

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Comment 5 & 6 still remains.