1363388 - Assertion failure: aScriptGlobalObject || !mAnimationController || mAnimationController->IsPausedByType( nsSMILTimeContainer::PAUSE_PAGEHIDE | nsSMI dom/base/nsDocument.cpp:4744

Status: RESOLVED WORKSFORME

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

Description

[Carsten Book [:Tomcat]]

Attachment: crash stack

Assertion failure: aScriptGlobalObject || !mAnimationController || mAnimationController->IsPausedByType( nsSMILTimeContainer::PAUSE_PAGEHIDE | nsSMI
om/base/nsDocument.cpp:4744

Found via bughunter

Steps to reproduce:
Load -> http://ventas.globussistemas.net/Form/FrmPuntoVenta.aspx?TipMovi=V#no-back-button
--> Assertion failure

Comment 1

[Carsten Book [:Tomcat]]

regression from i guess bug Bug 1362003  or bug Bug 1362119

Comment 2

[Andrea Marchesini [:baku]]

I don't see how those 2 bugs can be related. kamil, do you have time to help me with mozregression?

Comment 3

[Andrea Marchesini [:baku]]

I can reproduce the crash with a build from 2017-01-01 (debug build only).

Comment 4

[Kamil Jozwiak [:kjozwiak]]

(In reply to Andrea Marchesini [:baku] from comment #2)
> I don't see how those 2 bugs can be related. kamil, do you have time to help
> me with mozregression?

I used mozregression on Ubuntu using "--build-type debug" and I could reproduce the crash with a build going all the way back to 2016-05-09 using the STR from comment#0. However, it seems like mozregression doesn't have debug builds that are older than 2016-05-09 so I can't go back any further and pinpoint the exact bug that caused this issue. Optimized builds are available past 2016-05-09 but I can only reproduce the issue with debug builds.
 
Results: (using --build-type debug via mozregression)

* 2016-05-09 - reproduced
* 2016-06-01 - reproduced
* 2016-07-02 - reproduced
* 2016-08-01 - reproduced
* 2016-09-01 - reproduced
* 2016-10-01 - reproduced
* 2016-11-01 - reproduced
* 2016-12-05 - reproduced
* 2017-01-01 - reproduced
* 2017-02-01 - reproduced
* 2017-03-01 - reproduced
* 2017-04-01 - reproduced
* 2017-05-09 - reproduced

Baku, I know you've reproduced it as per comment#3 but hopefully this gives you some more information when you're debugging.

Comment 5

[Carsten Book [:Tomcat]]

http://ventas.globussistemas.net/Form/FrmPuntoVenta.aspx?TipMovi=V#no-back-button is still reproducible with this assertion

Comment 6

[Tyson Smith [:tsmith]]

Attachment: testcase.html

I am seeing this assertion frequently while fuzzing. Here is a testcase.

Comment 7

[Tyson Smith [:tsmith]]

Attachment: prefs.js

This will help with reproduction.

Comment 8

[Andrea Marchesini [:baku]]

This assertion was introduced in bug 536834. 

Here a stack trace:

#0  0x00007f2c65afad9a in nsDocument::SetScriptGlobalObject (this=0x1b58340, aScriptGlobalObject=0x0) at /home/baku/Sources/m/barfoo/src/dom/base/nsDocument.cpp:4900
#1  0x00007f2c65b0823f in nsDocument::Destroy (this=0x1b58340) at /home/baku/Sources/m/barfoo/src/dom/base/nsDocument.cpp:8280
#2  0x00007f2c6843b3b8 in nsDocumentViewer::Destroy (this=0x16aee10) at /home/baku/Sources/m/barfoo/src/layout/base/nsDocumentViewer.cpp:1777
#3  0x00007f2c6843c51b in nsDocumentViewer::Show (this=0x161dd40) at /home/baku/Sources/m/barfoo/src/layout/base/nsDocumentViewer.cpp:2108
#4  0x00007f2c6849dfb2 in nsPresContext::EnsureVisible (this=0x1798840) at /home/baku/Sources/m/barfoo/src/layout/base/nsPresContext.cpp:2256
#5  0x00007f2c683c26f5 in mozilla::PresShell::UnsuppressAndInvalidate (this=0x1723cc0) at /home/baku/Sources/m/barfoo/src/layout/base/PresShell.cpp:3909
#6  0x00007f2c683d58e7 in mozilla::PresShell::ProcessReflowCommands (this=0x1723cc0, aInterruptible=true) at /home/baku/Sources/m/barfoo/src/layout/base/PresShell.cpp:9157
#7  0x00007f2c683c37fc in mozilla::PresShell::DoFlushPendingNotifications (this=0x1723cc0, aFlush=...) at /home/baku/Sources/m/barfoo/src/layout/base/PresShell.cpp:4261
#8  0x00007f2c68388f60 in nsIPresShell::FlushPendingNotifications (this=0x1723cc0, aType=...) at /home/baku/Sources/m/barfoo/src/layout/base/nsIPresShell.h:581
#9  0x00007f2c683c2d24 in mozilla::PresShell::DoFlushPendingNotifications (this=0x1723cc0, aType=mozilla::FlushType::InterruptibleLayout) at /home/baku/Sources/m/barfoo/src/layout/base/PresShell.cpp:4080
#10 0x00007f2c6590db3b in nsIPresShell::FlushPendingNotifications (this=0x1723cc0, aType=mozilla::FlushType::InterruptibleLayout) at /home/baku/Sources/m/barfoo/src/layout/base/nsIPresShell.h:572
#11 0x00007f2c683c2c1f in mozilla::PresShell::HandlePostedReflowCallbacks (this=0x1723cc0, aInterruptible=true) at /home/baku/Sources/m/barfoo/src/layout/base/PresShell.cpp:4049
#12 0x00007f2c683d3f42 in mozilla::PresShell::DidDoReflow (this=0x1723cc0, aInterruptible=true) at /home/baku/Sources/m/barfoo/src/layout/base/PresShell.cpp:8768
#13 0x00007f2c683d57fc in mozilla::PresShell::ProcessReflowCommands (this=0x1723cc0, aInterruptible=true) at /home/baku/Sources/m/barfoo/src/layout/base/PresShell.cpp:9124
#14 0x00007f2c683c37fc in mozilla::PresShell::DoFlushPendingNotifications (this=0x1723cc0, aFlush=...) at /home/baku/Sources/m/barfoo/src/layout/base/PresShell.cpp:4261
#15 0x00007f2c68388f60 in nsIPresShell::FlushPendingNotifications (this=0x1723cc0, aType=...) at /home/baku/Sources/m/barfoo/src/layout/base/nsIPresShell.h:581
#16 0x00007f2c68386a8b in nsRefreshDriver::Tick (this=0x171a200, aNowEpoch=1520439455469470, aNowTime=...) at /home/baku/Sources/m/barfoo/src/layout/base/nsRefreshDriver.cpp:1944
#17 0x00007f2c6838a346 in mozilla::RefreshDriverTimer::TickDriver (driver=0x171a200, jsnow=1520439455469470, now=...) at /home/baku/Sources/m/barfoo/src/layout/base/nsRefreshDriver.cpp:340
#18 0x00007f2c6838a0e0 in mozilla::RefreshDriverTimer::TickRefreshDrivers (this=0x1b90c80, aJsNow=1520439455469470, aNow=..., aDrivers=...) at /home/baku/Sources/m/barfoo/src/layout/base/nsRefreshDriver.cpp:310
#19 0x00007f2c6838a25f in mozilla::RefreshDriverTimer::Tick (this=0x1b90c80, jsnow=1520439455469470, now=...) at /home/baku/Sources/m/barfoo/src/layout/base/nsRefreshDriver.cpp:332
#20 0x00007f2c6838ba48 in mozilla::VsyncRefreshDriverTimer::RunRefreshDrivers (this=0x1b90c80, aTimeStamp=...) at /home/baku/Sources/m/barfoo/src/layout/base/nsRefreshDriver.cpp:773
#21 0x00007f2c6838b5a9 in mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::TickRefreshDriver (this=0x1b90ce0, aVsyncTimestamp=...)
    at /home/baku/Sources/m/barfoo/src/layout/base/nsRefreshDriver.cpp:686
#22 0x00007f2c6838b054 in mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::NotifyVsync (this=0x1b90ce0, aVsyncTimestamp=...) at /home/baku/Sources/m/barfoo/src/layout/base/nsRefreshDriver.cpp:587
#23 0x00007f2c687a3ac6 in mozilla::layout::VsyncChild::RecvNotify (this=0x1b90b10, aVsyncTimestamp=...) at /home/baku/Sources/m/barfoo/src/layout/ipc/VsyncChild.cpp:68
#24 0x00007f2c64a663c4 in mozilla::layout::PVsyncChild::OnMessageReceived (this=0x1b90b10, msg__=...) at /home/baku/Sources/m/barfoo/build/ipc/ipdl/PVsyncChild.cpp:156
#25 0x00007f2c64992d84 in mozilla::ipc::PBackgroundChild::OnMessageReceived (this=0x1dfa540, msg__=...) at /home/baku/Sources/m/barfoo/build/ipc/ipdl/PBackgroundChild.cpp:1968
#26 0x00007f2c646bf101 in mozilla::ipc::MessageChannel::DispatchAsyncMessage (this=0x1dfa660, aMsg=...) at /home/baku/Sources/m/barfoo/src/ipc/glue/MessageChannel.cpp:2133
#27 0x00007f2c646beb8b in mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) (this=0x1dfa660, aMsg=<unknown type in /home/baku/Sources/m/barfoo/build/dist/bin/libxul.so, CU 0x3026e67, DIE 0x30c3b6d>)
    at /home/baku/Sources/m/barfoo/src/ipc/glue/MessageChannel.cpp:2063

Comment 9

[Daniel Holbert [:dholbert]]

I can't reproduce any crash or assertions in an up-to-date debug build, when:
(1) visiting the URL referenced above
or
(2) viewing the attached testcase, using a Firefox profile with the attached prefs.js file.

Tyson, can you still repro with this or another testcase?

Comment 10

[Tyson Smith [:tsmith]]

No I can't reproduce the issue either. It was last reported by fuzzers running 20181220-a1e34d928bad.

Comment 11

[Daniel Holbert [:dholbert]]

Thanks! Let's close as WFM then. Not gonna spend cycles trying to add a crashtest at this point, given that we only confirmed this crashing with the (fairly-substantial) prefs.js file. Though if someone can come up with a crashtest that reproduces the crash in old builds with a reasonably small set of pref-tweaks, I'd be happy to take it.