1086931 - [Window management] crash in mozilla::layers::TouchBlockState::HasEvents() const

Status: VERIFIED FIXED

(Core :: Panning and Zooming, defect)

Description

[KTucker [:KTucker][Inactive 3/4/2016]]

This bug was filed from the Socorro interface and is 
report bp-00135df1-857a-446b-b44c-393282141021.
=============================================================

Description:
A crash occurred when scrolling a website with a lot of images on the webpage and locking/unlocking the phone.

Repro Steps:
1)  Updated Flame to Build ID: 20141021001201
2)  Open the browser and go to www.gamespot.com
3)  While the page is loading, keep scrolling up and down the page.
4)  Lock the phone and unlock the phone.
5)  Repeat steps 3 and 4 multiple times.

Actual:
A crash will occur when scrolling a webpage with a lot of images on it and locking/unlocking the dut.

Expected:
No crash occurs.

Environmental Variables
Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash)
Build ID: 20141021001201
Gecko: https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/ee86921a986f
Gaia: e458f5804c0851eb4e93c9eb143fe044988cecda
Platform Version: 34.0
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Notes:
Repro frequency: 1/10 attempts
See attached: Video

Comment 1

[Marcia Knous [:marcia]]

Is there a video? I don't see one attached. Also if you can recall what site you saw it on, would give us a better chance to repro.

Comment 2

[Marcia Knous [:marcia]]

Also adding Botond to cc list since he touched code in this area according to the stack: http://hg.mozilla.org/releases/mozilla-b2g34_v2_1/annotate/ee86921a986f/gfx/layers/apz/src/InputBlockState.cpp#l140

Comment 3

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

I think there's a race condition in the code where the APZC might get destroy()d on the compositor thread while the ProcessPendingInputBlocks is running on the controller thread, which could result in this.

Comment 4

[Tony Chung [:tchung]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #3)
> I think there's a race condition in the code where the APZC might get
> destroy()d on the compositor thread while the ProcessPendingInputBlocks is
> running on the controller thread, which could result in this.

Kats, do you any tips on how a tester can get into this race condition, and try to manually reproduce?

Comment 5

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

Most likely the critical elements are to load a page with slow touchstart event listeners (a big page like gamespot.com or nytimes.com is a likely candidate, or you could construct one), and then locking the device as quickly as possible after touching the screen to do a pan for example. That should cause the APZC to get destroyed while the touch event listener is still going, and then the crash should trigger when it listener finishes running.

Comment 6

[KTucker [:KTucker][Inactive 3/4/2016]]

Thank you Kartikaya for the information. I was able to reproduce this crash once more by navigating through the Gamespot website, scrolling the page and locking/unlocking the device. I have tried this several more times and I still haven't got a solid repro or video for this issue. I will keep working on it. Once thing i did notice was that scrolling will completely break after awhile. The user will not be able to scroll the webpage at all. This has happened to me twice in my many attempts. This could be related or a completely separate issue.

Comment 7

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

[Blocking Requested - why for this release]: I'm not convinced this actually needs to be blocking because it seems fairly rare, but I'm requesting blocking to know what the release drivers think. The patch series I'm working on in bug 1083395 will fix this, but that will land on 2.2 and will NOT be upliftable to 2.1. So if we want to fix this in 2.1 we will need to either land a fix before I land bug 1083395 and uplift that, or fix it directly in 2.1 code at some point. So I would like to know if this is considered blocking to determine if we should spend time on it or not.

Comment 8

[Tony Chung [:tchung]]

Given that the reproduction rate is low, and it's not showing up as a topcrash in Kairo's report, i'm inclined to agree with Kats that we should let this ride the trains.  It's really too late to risk landing complicated patches.  I'm going to 2.1-, and move this to 2.2?.  But if this surfaces up on the top crashes or we can find large reproducibility rate, we can renom.

Comment 9

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

This should be fixed by bug 1083395 which moves around a lot of this code.

Comment 10

[Duane Dixon [:ddixon]]

Unable to reproduce issue on Flame 2.1 build (Full Flash, nightly, 319 MB memory). 

I spent 1+ hours attempting to repro this bug, but could not get the Browser app to crash (gamespot.com). 

Environmental Variables:
Device: Flame 2.1
Build ID: 20141028001203
Gaia: a0174f7166745256aaca1cb3aa9f894033fbffa6
Gecko: 43bda3541f6b
Version: 34.0 (2.1)
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 11

[Joshua Mitchell (Inactive)]

Issue is fixed, removing steps-wanted keyword

Comment 12

[Yeojin Chung [:YeojinC]]

Changing the status to VERIFIED based on Comment 9, Comment 10, and Comment 11.