Closed
Bug 1373912
Opened 7 years ago
Closed 4 years ago
Crash in mozilla::dom::TimeoutManager::~TimeoutManager
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox54 | --- | unaffected |
firefox55 | --- | wontfix |
firefox56 | --- | wontfix |
firefox57 | --- | wontfix |
firefox58 | --- | wontfix |
firefox59 | --- | wontfix |
firefox66 | --- | ? |
firefox67 | --- | ? |
firefox68 | --- | ? |
People
(Reporter: philipp, Assigned: farre)
References
Details
(Keywords: crash, regression)
Crash Data
This bug was filed from the Socorro interface and is report bp-7084d971-6b17-431f-9fc9-93bc40170616. ============================================================= Crashing Thread (0) Frame Module Signature Source 0 xul.dll mozilla::dom::TimeoutManager::~TimeoutManager() dom/base/TimeoutManager.cpp:283 1 xul.dll nsPIDOMWindow<nsISupports>::~nsPIDOMWindow<nsISupports>() dom/base/nsGlobalWindow.cpp:1026 2 xul.dll nsGlobalWindow::~nsGlobalWindow() dom/base/nsGlobalWindow.cpp:1826 3 xul.dll nsGlobalWindow::`scalar deleting destructor'(unsigned int) 4 xul.dll nsGlobalWindow::DeleteCycleCollectable() dom/base/nsGlobalWindow.cpp:2230 5 xul.dll mozilla::DOMEventTargetHelper::cycleCollection::DeleteCycleCollectable(void*) obj-firefox/dist/include/mozilla/DOMEventTargetHelper.h:69 6 xul.dll SnowWhiteKiller::~SnowWhiteKiller() xpcom/base/nsCycleCollector.cpp:2651 7 xul.dll nsCycleCollector::FreeSnowWhite(bool) xpcom/base/nsCycleCollector.cpp:2826 8 xul.dll nsCycleCollector::BeginCollection(ccType, nsICycleCollectorListener*) xpcom/base/nsCycleCollector.cpp:3829 9 xul.dll nsCycleCollector::Collect(ccType, js::SliceBudget&, nsICycleCollectorListener*, bool) xpcom/base/nsCycleCollector.cpp:3650 10 xul.dll nsCycleCollector_collect(nsICycleCollectorListener*) xpcom/base/nsCycleCollector.cpp:4187 11 xul.dll nsJSContext::CycleCollectNow(nsICycleCollectorListener*, int) dom/base/nsJSEnvironment.cpp:1633 12 xul.dll nsJSEnvironmentObserver::Observe(nsISupports*, char const*, char16_t const*) dom/base/nsJSEnvironment.cpp:526 13 xul.dll nsObserverList::NotifyObservers(nsISupports*, char const*, char16_t const*) xpcom/ds/nsObserverList.cpp:112 14 xul.dll nsObserverService::NotifyObservers(nsISupports*, char const*, char16_t const*) xpcom/ds/nsObserverService.cpp:288 15 xul.dll nsThread::DoMainThreadSpecificProcessing(bool) xpcom/threads/nsThread.cpp:1641 16 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp:1326 17 xul.dll mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp:96 18 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc:231 19 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc:211 20 xul.dll nsBaseAppShell::Run() widget/nsBaseAppShell.cpp:156 21 xul.dll nsAppShell::Run() widget/windows/nsAppShell.cpp:271 22 xul.dll nsAppStartup::Run() toolkit/components/startup/nsAppStartup.cpp:283 23 xul.dll XREMain::XRE_mainRun() toolkit/xre/nsAppRunner.cpp:4569 24 xul.dll XREMain::XRE_main(int, char** const, mozilla::BootstrapConfig const&) toolkit/xre/nsAppRunner.cpp:4749 25 xul.dll XRE_main(int, char** const, mozilla::BootstrapConfig const&) toolkit/xre/nsAppRunner.cpp:4844 26 xul.dll mozilla::BootstrapImpl::XRE_main(int, char** const, mozilla::BootstrapConfig const&) toolkit/xre/Bootstrap.cpp:45 27 firefox.exe wmain toolkit/xre/nsWindowsWMain.cpp:115 28 firefox.exe __scrt_common_main_seh f:/dd/vctools/crt/vcstartup/src/startup/exe_common.inl:253 29 kernel32.dll BaseThreadInitThunk 30 ntdll.dll __RtlUserThreadStart 31 ntdll.dll _RtlUserThreadStart crashes with this signature are regressing since 55.0a1 - they are happening with MOZ_RELEASE_ASSERT(mWindow.AsInner()->InnerObjectsFreed()) that got added in bug 1364858.
Updated•7 years ago
|
Flags: needinfo?(afarre)
Assignee | ||
Comment 1•7 years ago
|
||
So ~TimeoutManager is only destroyed when the Window is, right? At that point I'd expect that InnerObjectsFreed should've been called. Or am I missing something. I'm thinking that this might be a too strict assert. It should be true, but because some transient state it happens? Do you have an idea Ben? Should we just remove the assert?
Flags: needinfo?(afarre) → needinfo?(bkelly)
Comment 2•7 years ago
|
||
It appears we don't call nsGlobalWindow::FreeInnerObjects() when the window is cleaned up via cycle collection. So the assertion is indeed too strict. The question, though, is how to handle the throttle timer correctly if we enter this cleanup path. We are checking InnerObjectsFreed() path to avoid creating the timer, right? That may not be adequate now.
Flags: needinfo?(bkelly) → needinfo?(afarre)
Comment 3•7 years ago
|
||
(In reply to Ben Kelly [reviewing, but slowly][:bkelly] from comment #2) > It appears we don't call nsGlobalWindow::FreeInnerObjects() when the window > is cleaned up via cycle collection. We don't? How can that happen? Is it only during shutdown? But anyhow, if it happens that is quite a bad bug. We don't end up calling NotifyDOMWindowDestroyed or anything like that.
Comment 4•7 years ago
|
||
(In reply to Olli Pettay [:smaug] from comment #3) > (In reply to Ben Kelly [reviewing, but slowly][:bkelly] from comment #2) > > It appears we don't call nsGlobalWindow::FreeInnerObjects() when the window > > is cleaned up via cycle collection. > We don't? How can that happen? Is it only during shutdown? Maybe we do, but I don't see it. Or maybe we release TimeoutManager before calling FreeInnerObjects() in CC case.
Comment 5•7 years ago
|
||
Hmm, this is memory-pressure.
Assignee | ||
Comment 6•7 years ago
|
||
I'll have one more look at the timer handling, but I'm leaning towards handling this by just allowing the timer to for multiple times and add the timer itself as a condition for creating the timer. Or something like that.
Flags: needinfo?(afarre)
Comment 7•7 years ago
|
||
Gonna mark this as fix-optional for 55 given the low volume.
Updated•7 years ago
|
Assignee: nobody → afarre
Priority: -- → P3
Updated•7 years ago
|
Updated•7 years ago
|
status-firefox58:
--- → fix-optional
status-firefox59:
--- → fix-optional
Comment 8•6 years ago
|
||
bp-eb1c561a-6f31-4dd7-95b2-04cbf0171215 (previously unsubmitted from a few days ago, so I don't know what was going on)
Comment 9•6 years ago
|
||
bp-86033717-f53e-41e9-8e6c-aae040180330 - not reproducible :(
Comment 10•5 years ago
|
||
I'm not seeing reports for this in 66. The ones listed on top right of this bug are bogus reports, the top of the stack is wrong.
But 65 seems to have still 2 valid crashes.
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
Updated•5 years ago
|
Comment 11•4 years ago
|
||
Closing because no crashes reported for 12 weeks.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•