1471107 - Intermittent Assertion failure: mActiveSuppressDisplayport >= 0, at layout/base/PresShell.cpp:8575

Status: RESOLVED FIXED

(Core :: Graphics, defect, P5)

Description

[Treeherder Bug Filer]

Filed by: nerli [at] mozilla.com

https://treeherder.mozilla.org/logviewer.html#?job_id=184824159&repo=autoland

https://queue.taskcluster.net/v1/task/Cn0sXUbYQdOpC0M4deX0nQ/runs/0/artifacts/public/logs/live_backing.log

17:48:26     INFO - GECKO(977) | --DOCSHELL 0x121366000 == 5 [pid = 982] [id = {2f3db714-6ff4-1741-822e-2a67d39c206b}]
17:48:26     INFO - GECKO(977) | --DOCSHELL 0x12506b800 == 4 [pid = 982] [id = {2b5ca041-b525-b240-8c8e-51ccdab2c18e}]
17:48:26     INFO - GECKO(977) | --DOMWINDOW == 17 (0x12125aa00) [pid = 982] [serial = 22] [outer = 0x0] [url = about:blank]
17:48:26     INFO - GECKO(977) | --DOMWINDOW == 16 (0x12125d200) [pid = 982] [serial = 25] [outer = 0x0] [url = http://mochi.test:8888/browser/browser/components/sessionstore/test/browser_463206_sample.html]
17:48:26     INFO - GECKO(977) | --DOMWINDOW == 15 (0x12125e600) [pid = 982] [serial = 41] [outer = 0x0] [url = about:blank]
17:48:26     INFO - GECKO(977) | --DOMWINDOW == 14 (0x121a38600) [pid = 982] [serial = 38] [outer = 0x0] [url = about:blank]
17:48:26     INFO - GECKO(977) | --DOCSHELL 0x119f44000 == 3 [pid = 982] [id = {30c03e5c-9f51-284d-9152-cd4cd1b81a87}]
17:48:26     INFO - GECKO(977) | --DOMWINDOW == 13 (0x12125da00) [pid = 982] [serial = 46] [outer = 0x0] [url = about:blank]
17:48:26     INFO - GECKO(977) | --DOMWINDOW == 12 (0x12125d600) [pid = 982] [serial = 44] [outer = 0x0] [url = about:blank]
17:48:27     INFO - GECKO(977) | Assertion failure: mActiveSuppressDisplayport >= 0, at /builds/worker/workspace/build/src/layout/base/PresShell.cpp:8575
17:48:27     INFO - GECKO(977) | ###!!! [Parent][RunMessage] Error: Channel error: cannot send/recv
17:48:27     INFO - GECKO(977) | ###!!! [Parent][RunMessage] Error: Channel error: cannot send/recv
17:48:27     INFO - GECKO(977) | ###!!! [Parent][RunMessage] Error: Channel error: cannot send/recv
17:48:27     INFO - GECKO(977) | ###!!! [Parent][RunMessage] Error: Channel error: cannot send/recv
17:48:27     INFO - GECKO(977) | ###!!! [Parent][MessageChannel] Error: (msgtype=0x160001,name=PBrowser::Msg_AsyncMessage) Channel error: cannot send/recv
17:48:27     INFO - GECKO(977) | JavaScript error: resource:///modules/sessionstore/TabStateFlusher.jsm, line 85: NS_ERROR_UNEXPECTED:
17:48:27     INFO - GECKO(977) | ###!!! [Parent][MessageChannel] Error: (msgtype=0x160063,name=PBrowser::Msg_ParentActivated) Channel error: cannot send/recv
17:48:27     INFO - GECKO(977) | ###!!! [Parent][MessageChannel] Error: (msgtype=0x160063,name=PBrowser::Msg_ParentActivated) Channel error: cannot send/recv
17:48:27     INFO - GECKO(977) | ###!!! [Parent][MessageChannel] Error: (msgtype=0x2D0053,name=PContent::Msg_Deactivate) Channel error: cannot send/recv
17:48:27     INFO - GECKO(977) | ###!!! [Parent][MessageChannel] Error: (msgtype=0x160065,name=PBrowser::Msg_StopIMEStateManagement) Channel error: cannot send/recv
17:48:27     INFO - GECKO(977) | ###!!! [Parent][MessageChannel] Error: (msgtype=0x160080,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv
17:48:27     INFO - GECKO(977) | ###!!! [Parent][MessageChannel] Error: (msgtype=0x160080,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv

Comment 2

[Intermittent Failures Robot]

30 failures in 718 pushes (0.042 failures/push) were associated with this bug in the last 7 days. 

This is the #38 most frequent failure this week.  

** This failure happened more than 30 times this week! Resolving this bug is a high priority. **

** Try to resolve this bug as soon as possible. If unresolved for 2 weeks, the affected test(s) may be disabled. **  

Repository breakdown:
* autoland: 15
* mozilla-inbound: 13
* try: 1
* mozilla-central: 1

Platform breakdown:
* osx-10-10: 30

For more details, see:
https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?bug=1471107&startday=2018-06-25&endday=2018-07-01&tree=trunk

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 1471107 - TabChild's should not attempt to unsuppress displayports on PresShells that don't exist yet. r?kats

It's possible to suppress a displayport on a PresShell multiple times, and then for that PresShell to
be destroyed. If the TabChild tries to unsuppress the displayport for its top-level PresShell, and it
has already been destroyed, it will attempt to create a new one and unsuppress. However, unsuppressing
the displayport on a brand new PresShell shouldn't be possible because PresShells don't start suppressed.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

Try build at https://treeherder.mozilla.org/#/jobs?repo=try&revision=4b358e70f5510523705f9876d5a0ae5a4b08668a

Comment 6

[Intermittent Failures Robot]

13 failures in 622 pushes (0.021 failures/push) were associated with this bug in the last 7 days.    

Repository breakdown:
* autoland: 9
* mozilla-inbound: 2
* mozilla-central: 2

Platform breakdown:
* osx-10-10: 13

For more details, see:
https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?bug=1471107&startday=2018-07-02&endday=2018-07-08&tree=trunk

Comment 7

[Mike Conley (:mconley) (:⚙️)]

Hey kats, I think I understand what's happening here. It looks like we call TabParent::SuppressDisplayport(true) here:

https://searchfox.org/mozilla-central/rev/28daa2806c89684b3dfa4f0b551db1d099dda7c2/dom/ipc/TabParent.cpp#3589

and TabParent::SuppressDisplayport(false) here:

https://searchfox.org/mozilla-central/rev/28daa2806c89684b3dfa4f0b551db1d099dda7c2/dom/ipc/TabParent.cpp#3589

and it seems like it's possible in between those two calls for the underlying PresShell to get destroyed and replaced.

So I think we have a few options:

1. Somehow cache the previous mActiveSuppressDisplayport when destroying a PresShell, and if a new one gets created, copy it into the new one.

2. Do suppression tracking at a higher-level - over something that can't get swapped out and replaced. Does the PresShell have something like an outer window? Maybe the DocumentViewer?

3. Get rid of the assertion in the PresShell and ignore attempts to unsuppress when the suppression level is 0.

Do you have an opinion, kats?

Comment 8

[Kartikaya Gupta (email:[e-mail])]

I'm leaning towards option 3. It's the simplest to do. The downside is that in these scenarios the new content loaded into the tab will not have a displayport suppressed, but it's a rare case (tab loads new content while the user is resizing the window) and I'm not too concerned about that.

Is there any way that a presshell could get detached from a TabChild and still be used somewhere else? If so that would be more concerning because if that happened during a live resize then that presshell would get stuck in a suppressed state.

Comment 9

[Mike Conley (:mconley) (:⚙️)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #8)
> Is there any way that a presshell could get detached from a TabChild and
> still be used somewhere else? If so that would be more concerning because if
> that happened during a live resize then that presshell would get stuck in a
> suppressed state.

Oh, geez, good question. Maybe? The only place I can think where that _might_ happen is when we're saving presentation state in the bfcache...

Hey mrbkap, do you know the answer to kats' question?

Comment 10

[Mike Conley (:mconley) (:⚙️)]

Or maybe nika? I think you've had some dealings with bfcache recently.

Comment 11

[Nika Layzell [:nika] (ooo, ni? for response)]

I am unfortunately not sure what's going on here off the top of my head :-/. Haven't actually interacted with PresShell that much.

Comment 12

[Mike Conley (:mconley) (:⚙️)]

Okay, thanks nika.

Maybe ehsan knows the answer to kats' question? (See comment 9)

Comment 13

[(no longer active)]

(In reply to Mike Conley (:mconley) (:⚙️) (PTO Jul 24th-Aug 6th)) from comment #12)
> Okay, thanks nika.
> 
> Maybe ehsan knows the answer to kats' question? (See comment 9)

I can't think of any such case off the top of my head...

Comment 14

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 1471107 - Get rid of assertion and handle the already-unsuppressed displayport case in PresShell. r?kats

Comment 15

[Phabricator Automation]

Comment on attachment 8991981 [details]
Bug 1471107 - Get rid of assertion and handle the already-unsuppressed displayport case in PresShell. r?kats

Kartikaya Gupta (email:[e-mail]) has approved the revision.

https://phabricator.services.mozilla.com/D2130

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2adb01963b2d
Get rid of assertion and handle the already-unsuppressed displayport case in PresShell. r=kats

Comment 17

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/2adb01963b2d

Comment 18

[Intermittent Failures Robot]

24 failures in 623 pushes (0.039 failures/push) were associated with this bug in the last 7 days.    

Repository breakdown:
* mozilla-inbound: 12
* autoland: 12

Platform breakdown:
* osx-10-10: 24

For more details, see:
https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?bug=1471107&startday=2018-07-09&endday=2018-07-15&tree=trunk