1318572 - Intermittent docshell/test/browser/browser_bug388121-2.js | application crashed [@ mozilla::layers::CrossProcessCompositorBridgeParent::AllocPAPZCTreeManagerParent]

Status: RESOLVED DUPLICATE of bug 1322633

(Core :: Panning and Zooming, defect, P3)

Description

[Treeherder Bug Filer]

Filed by: philringnalda [at] gmail.com

https://treeherder.mozilla.org/logviewer.html#?job_id=39412986&repo=mozilla-inbound

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

Comment 1

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

Assertion failure is at https://hg.mozilla.org/integration/mozilla-inbound/file/d607a23fc3dc64956e68b588e53772b9aef48f4f/gfx/layers/ipc/CrossProcessCompositorBridgeParent.cpp#l194

This doesn't seem like it should ever happen - dvander, could this be some race condition where we try to create a APZC after the parent side has torn down the layer tree state?

Comment 2

[David Anderson [:dvander] - inactive, e-mail if emergency]

I've seen this a few times now, usually when the GPU process restarts. Pretty easy to get on try:

https://treeherder.mozilla.org/#/jobs?repo=try&author=[e-mail]&selectedJob=31364521

Ryan, is this something you could look at?

Comment 3

[Ryan Hunt [:rhunt]]

I ran into this assert when I was working on device resets and the gpu process. I'll see if one of the patches I wrote with that can reproduce this. I'll also see if some additional logs in a try run will help.

Comment 4

[Ryan Hunt [:rhunt]]

I think this is a different assert than the one that David and I were thinking of.

This one seems to be that the LayerTreeState has not been initialized yet, or has been destroyed by the time we try and create a PAPZCTreeManager. The issue we've been getting with GPU process restarts was related to a race condition with the initalization of PAPZ, which I'm hoping to clean up in bug 1320817.

I don't see an obvious way that we could create a PAPZCTreeManager after the LayerTreeState has been destroyed. We'd somehow need to get a TabChild::Show after the tab has been shutting down, but I don't believe that's possible. Or else get a TabChild::ReinitRendering after the tab has been shutting down. That would make it a gpu process restart issue.

Looking at bug 1316632 comment 33, that might be what's going on. If that were to happen we would definitely run into this assert. The fix for that just landed so hopefully that fixes this.

Comment 5

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

It's only happened twice ever [1], so it's going to be hard to say definitively if bug 1316632 fixed it. I'm going to optimistically close this as fixed, and we can reopen and investigate if it happens again.

[1] https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1318572&startday=2016-11-13&endday=2016-12-04&tree=trunk

Comment 7

[Intermittent Failures Robot]

1 failures in 888 pushes (0.001 failures/push) were associated with this bug in the last 7 days.   

Repository breakdown:
* mozilla-esr52: 1

Platform breakdown:
* windows8-64: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1318572&startday=2017-07-31&endday=2017-08-06&tree=all

Comment 8

[Intermittent Failures Robot]

1 failures in 939 pushes (0.001 failures/push) were associated with this bug in the last 7 days.   

Repository breakdown:
* mozilla-esr52: 1

Platform breakdown:
* linux64: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1318572&startday=2017-08-28&endday=2017-09-03&tree=all