1. private url.

Assertion failure: timeout->mFiringIndex > mLastFiringIndex, at z:/build/build/src/dom/base/TimeoutManager.cpp:938
#01: mozilla::dom::TimeoutExecutor::Run() [dom/base/TimeoutExecutor.cpp:233]
#02: IdleRunnableWrapper::Run() [xpcom/threads/nsThreadUtils.cpp:319]
#03: nsThread::ProcessNextEvent(bool,bool *) [xpcom/threads/nsThread.cpp:1149]
#04: NS_ProcessNextEvent(nsIThread *,bool) [xpcom/threads/nsThreadUtils.cpp:474]
#05: mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate *) [ipc/glue/MessagePump.cpp:88]
#06: MessageLoop::RunHandler() [ipc/chromium/src/base/message_loop.cc:309]
#07: MessageLoop::Run() [ipc/chromium/src/base/message_loop.cc:291]
#08: nsBaseAppShell::Run() [widget/nsBaseAppShell.cpp:139]
#09: nsAppShell::Run() [widget/windows/nsAppShell.cpp:411]
#10: XRE_RunAppShell() [toolkit/xre/nsEmbedFunctions.cpp:908]
#11: mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate *) [ipc/glue/MessagePump.cpp:238]
#12: MessageLoop::RunHandler() [ipc/chromium/src/base/message_loop.cc:309]
#13: MessageLoop::Run() [ipc/chromium/src/base/message_loop.cc:291]
#14: XRE_InitChildProcess(int,char * * const,XREChildData const *) [toolkit/xre/nsEmbedFunctions.cpp:750]
#15: NS_internal_main(int,char * *,char * *) [browser/app/nsBrowserApp.cpp:265]
#16: wmain [toolkit/xre/nsWindowsWMain.cpp:129]
#17: static int __scrt_common_main_seh() [f:/dd/vctools/crt/vcstartup/src/startup/exe_common.inl:288]
#18: KERNEL32.DLL + 0x13dc4
#19: ntdll.dll + 0x73691

Windows and Linux Nightly 67 at least.

Bughunter has seen this on two urls on a video sharing site. One was NSFW and the other was a copyrighted movie so I won't share them here. I'll keep an eye out for better urls but hopefully you can figure it out without them.

Is this a regression? Bug 1270059 changed this code quite a bit.

Not sure. I wasn't able to reproduce this time on Fedora, Ubuntu or Windows 10. I'll try again later.

After reproducing a couple of times on Ubuntu, I am once again unable to reproduce. The movie url has been taken down. I've set up a reload loop using Nightly to see if it will eventually assert. If I can do that, I'll try with Beta. I've also loaded 204 other mp4 urls from this site that Bughunter has tested in the past to see if this is reproducible elsewhere.

Another stack with this assertion:

Assertion failure: timeout->mFiringIndex > mLastFiringIndex, at z:/build/build/src/dom/base/TimeoutManager.cpp:938
#01: mozilla::dom::TimeoutExecutor::Notify(nsITimer *) [dom/base/TimeoutExecutor.cpp:243]
#02: nsTimerImpl::Fire(int) [xpcom/threads/nsTimerImpl.cpp:571]
#03: nsTimerEvent::Run() [xpcom/threads/TimerThread.cpp:260]
#04: mozilla::ThrottledEventQueue::Inner::ExecuteRunnable() [xpcom/threads/ThrottledEventQueue.cpp:231]
#05: mozilla::ThrottledEventQueue::Inner::Executor::Run() [xpcom/threads/ThrottledEventQueue.cpp:77]
#06: mozilla::SchedulerGroup::Runnable::Run() [xpcom/threads/SchedulerGroup.cpp:292]
#07: nsThread::ProcessNextEvent(bool,bool *) [xpcom/threads/nsThread.cpp:1149]
#08: NS_ProcessNextEvent(nsIThread *,bool) [xpcom/threads/nsThreadUtils.cpp:474]
#09: mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate *) [ipc/glue/MessagePump.cpp:88]
#10: MessageLoop::RunHandler() [ipc/chromium/src/base/message_loop.cc:309]

While the re-test found many examples of the assertion, attempting to reliably reproduce them manually was not possible. Ping me on irc @ bc if you need more information.

Hi Randell, since you added the assertion there, I'm thinking you may like to take a look.

I can finally (2700 runs this last time) repro. Seems to only happen on a multiple of 1 hour since content process startup.... it may just be a bug in the firing order assertion.

Backed out changeset 93b9c2a8212b (bug 1527414) for causing build bustages on TimeoutManager.cpp CLOSED TREE

Backout revision https://hg.mozilla.org/integration/mozilla-inbound/rev/e2a84fa236ea306b025f92be208b794470f68333

Failed push https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&revision=93b9c2a8212b6bb642676a82c84724c40eb95f4d

Failure logs https://treeherder.mozilla.org/logviewer.html#?job_id=229495197&repo=mozilla-inbound
https://treeherder.mozilla.org/logviewer.html#?job_id=229495176&repo=mozilla-inbound

:jesup could you please take a look?

https://hg.mozilla.org/mozilla-central/rev/01175f1ce46d

This is a link that should show if we get any Nightly assertions after the fix is in:
https://crash-stats.mozilla.com/signature/?product=Firefox&build_id=%3E20190221000000&version=67.0a1&signature=mozilla%3A%3Adom%3A%3ATimeoutManager%3A%3ARunTimeout&date=%3E%3D2019-02-14T16%3A19%3A00.000Z&date=%3C2019-02-21T16%3A19%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&page=1#reports

Bughunter has hit this on Windows and Linux on a url to a copyrighted movie on the original site where we first reproduced. So far just one url has reproduced. I haven't reproduced yet locally.

mozversion INFO | application_buildid: 20190223041557
mozversion INFO | application_changeset: 6924dd16f7b1e2e6ce71a8eb4cbe330d3e4745dc

Assertion failure: timeout->mFiringIndex > mLastFiringIndex, at z:/build/build/src/dom/base/TimeoutManager.cpp:976
#01: mozilla::dom::TimeoutExecutor::Run() [dom/base/TimeoutExecutor.cpp:233]
#02: IdleRunnableWrapper::Run() [xpcom/threads/nsThreadUtils.cpp:319]

jesup: ping me?

Definitely interested... no hits from the wild in the search above since the landing after updating the dates; the search really should be more like:

https://crash-stats.mozilla.com/signature/?product=Firefox&build_id=%3E20190221000000&version=67.0a1&signature=mozilla%3A%3Adom%3A%3ATimeoutManager%3A%3ARunTimeout&date=%3E%3D2019-02-21T16%3A19%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&page=1#reports

Ah, linkers.... the signature is coming in under TimeoutExecutor (due to inlining):

https://crash-stats.mozilla.com/signature/?moz_crash_reason=~timeout-%3EmFiringIndex%20%3E%20mLastFiringIndex&build_id=%3E20190221000000&signature=mozilla%3A%3Adom%3A%3ATimeoutExecutor%3A%3AMaybeExecute&date=%3E%3D2019-02-18T16%3A36%3A00.000Z&date=%3C2019-02-25T16%3A36%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&page=1#reports

Still getting hits after landing this fix; reopening and trying to repro again. I may back this off ASAP since I don't think the URLs are helping us much.

I've caught it in a local test again (after 1600 runs); it appears to be another case where nested event loops mess up the assertion code, but it does not look like a violation of spec.

Backing out the DIAGNOSTIC back down to DEBUG with r=smaug (and may well just disable entirely after more analysis).

https://hg.mozilla.org/mozilla-central/rev/3098f2ba2d33

hi jesup, any update on this one? (tracking for 68)

This is DEBUG-only, and it almost certainly a bug in the assertion, not in the functionality.

The leave-open keyword is there and there is no activity for 6 months.
:jesup, maybe it's time to close this bug?

The leave-open keyword is there and there is no activity for 6 months.
:jesup, maybe it's time to close this bug?

The leave-open keyword is there and there is no activity for 6 months.
:jesup, maybe it's time to close this bug?

The leave-open keyword is there and there is no activity for 6 months.
:jesup, maybe it's time to close this bug?

no way to reproduce any more. let's close it.