1520132 - Crash in mozilla::layers::UiCompositorControllerChild::OpenForSameProcess

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Julien Cristau [:jcristau]]

This bug is for crash report bp-3f5fd709-340e-44fa-982f-9fa980190115.

Top 10 frames of crashing thread:

0 libxul.so mozilla::layers::UiCompositorControllerChild::OpenForSameProcess gfx/layers/ipc/UiCompositorControllerChild.cpp:270
1 libxul.so mozilla::detail::RunnableMethodImpl<FdWatcher*, void  xpcom/threads/nsThreadUtils.h:1197
2 libxul.so mozilla::RunAndroidUiTasks widget/android/AndroidUiThread.cpp:360
3 base.odex base.odex@0x8dc515 
4 base.art (deleted) base.art @0xeb0aa 
5 base.art (deleted) base.art @0x32c16 
6 system@[e-mail] system@[e-mail]@0x4944c2 
7 base.art (deleted) base.art @0xe262e 
8 dalvik-main space (deleted) dalvik-main space @0x27326 
9 base.art (deleted) base.art @0x2c76e 

Focus crashes at 0xe5e5e859.

Comment 1

[Daniel Veditz [:dveditz]]

All the crashes appear to be UAFs in Focus. Not sure what's going on here -- 60 frames of android stuff and then a couple frames of us. Some runable that stuck around too long and got woken up after everything else went away? Guessing "sec-moderate" because it looks like it would require getting the system to wake up.

Comment 2

[Alex Gaynor [:Alex_Gaynor]]

Is it possible to make mWidget a RefPtr here?

Comment 3

[Kelsey Gilbert [:jgilbert]]

:mattwoodrow, can you triage this?

Comment 4

[Randall Barker [:rbarker]]

Attachment: Bug 1520132 - Ensure base widget pointer is null on Destroy()

Speculative fix for crash.

Comment 5

[Randall Barker [:rbarker]]

I'm not sure what else is need to land this. I guess it can't be landed from phabricator with lando?

Comment 6

[Alex Gaynor [:Alex_Gaynor]]

I believe lando does support secure revisions. RyanVM will know for sure.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

It does if you give it a Phabricator API token.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/autoland/rev/9571930df748

Comment 9

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/9571930df748

Comment 10

[Ryan VanderMeulen [:RyanVM]]

Do we want this on the Beta/GV65?

Comment 11

[Randall Barker [:rbarker]]

It was a speculative fix since I couldn't reproduce it. If it really did help I would say yes since it should be pretty harmless otherwise.

Comment 12

[Liz Henry (:lizzard)]

Since it's not certain that it helped I'll mark this wontfix for 66. If you feel strongly about wanting on 66 we can still uplift.

Comment 13

[Andrei Bodea[:andrei]]

Hello, I tried to reproduce this issue but I was unable to.
As I understood from the all information from this bug, I tried to reproduce it following this steps:

• I tried to close Fennec and let it for more hours like that.
• I tried to minimize Fennec and let it like that for few hours.

Normally Fennec would crash while it is on background or closed, something was rendering in background.
Please note that the crash volume was already low but according to crashstats the only affected version is 64.0.3.

Thanks,
Andrei

Comment 14

[Julien Cristau [:jcristau]]

Andrei this crash affects Focus not Fennec.

Comment 15

[Andrei Bodea[:andrei]]

Hello Julien,
I wasn't able to reproduce the issue on the latest Focus version from taskcluster and the one from Playstore with the instructions from Comment 13.
During my tests I will keep an eye for this issue and I will try always to have focus installed and let it in the background, I will come back with information once I will find something out.
Also, please note that now It's a week since I'm using only Focus as a browser on my phone and It didn't crashed once.