966476 - Settings app is killed when showing the passcode panel with the Hardware Composer turned on

Status: RESOLVED WORKSFORME

(Core :: Panning and Zooming, defect)

Description

[Sotaro Ikeda [:sotaro]]

Settings app is killed because of OOM during scrolling. I saw the crash on master hamachi. I did not saw the problem on b2g v1.3. The problem happens only when APZ is enabled. But the crash did not happens on v1.3. Other factor might affect to the crash.

STR
[1] start Settings app
[2] scroll to bottom of the page.
[3] scroll very quickly until top
[4] scroll very quickly until bottom

continue [3] [4] until, the app is killed by low memory killer.

Comment 1

[Sotaro Ikeda [:sotaro]]

Before the crash setting app's rendering becomes white.

Comment 2

[Natalya Kot [:nkot]]

here is another STR:

1. Open Settings
2. Open Screen Lock
3. Select to create Passcode
4. Type in the code
5. Tap "Create"

==> the Settings is killed, the user is unable to set Passcode

Comment 3

[Brogan Zumwalt [Inactive]]

Attachment: Logcat-Comment2

Logcat for issue described in Comment 2

Comment 4

[Natalya Kot [:nkot]]

blocking Sign in to WiFi from Settings as well

Comment 5

[Andreas Gal :gal]

Jason does this affect 1.3?

Comment 7

[Jason Smith [:jsmith]]

(In reply to Andreas Gal :gal from comment #5)
> Jason does this affect 1.3?

Nope.

Talked with Alexandre about this - he indicated he couldn't reproduce this when APZC is disabled. I've confirmed this as well - you only OOM here if APZC is enabled.

Comment 8

[Jason Smith [:jsmith]]

Vivien recommended I ping Botond about this, so I'm putting needinfo on him.

Comment 9

[Jason Smith [:jsmith]]

This was working on the 1/30/2014 build, busted on 1/31/2014 build. Working on translating to a range right now.

Comment 10

[Jason Smith [:jsmith]]

Working:

Build ID: 20140130040201 
Gecko: bf49e4428906 
Gaia: 0bc0e703df197d46dfffb9ac65cb85d2e3e10c4a 

Busted:

Build ID: 20140131095418 
Gecko: 735a648bca0d 
Gaia: aedd5c9636f305d4433491056a0ca984dfb859b1

Comment 11

[Jason Smith [:jsmith]]

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bf49e4428906&tochange=735a648bca0d

Comment 12

[Andreas Gal :gal]

APZC is enabled in 1.3 so it does affect 1.3 then?

Comment 13

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

sounds like a recent regression in code that hasn't been uplifted to 1.3 yet. I see a number of possibilities in that window but not sure which is most likely. Can we narrow the window further using inbound or local builds?

Also, when people run into this, does the memory usage increase gradually before OOMing (a leak) or does it just OOM on one set of giant allocation requests?

Comment 14

[Jason Smith [:jsmith]]

At a minimum, we can definitely can cut this window in half, as we now have two builds per day by default. Adding regression window wanted to cut this down to 12 hours.

Comment 15

[:gerard-majax]

On Nexus S, I'm reproducing this easily, even just taping in the settings or loading the settings can trigger. I've also reproduced on Desire Z, when tapping on the dialer keypad while performing some USSD.

Comment 16

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Unlike most of the APZ problems this kills the child, not the parent, so P2.

Let me know if there's anything we can help with, but I suspect that kats et al. have this under control.

Comment 17

[J Zimbrick]

Last Working Environmental Variables:
Device: Buri v1.4 Mozilla RIL
BuildID: 20140130040201
Gaia: 0bc0e703df197d46dfffb9ac65cb85d2e3e10c4a
Gecko: bf49e4428906
Version: 29.0a1
Base Image: V1.2-device.cfg

First Broken Environmental Variables:
Device: Buri v1.4 Mozilla RIL
BuildID: 20140130160200
Gaia: 09064f43116d1b965cb3ab6516fa0f1fa3c98a4c
Gecko: 6f544aa66c1a
Version: 29.0a1
Base Image: V1.2-device.cfg

Comment 18

[Jason Smith [:jsmith]]

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bf49e4428906&tochange=6f544aa66c1a

Comment 19

[Botond Ballo [:botond]]

(In reply to Jason Smith [:jsmith] from comment #18)
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=bf49e4428906&tochange=6f544aa66c1a

Maybe bug 956690?

Comment 20

[Jason Smith [:jsmith]]

Dale is going to manually verify a backout of bug 956690. If it verifies, then we'll back that patch out.

Comment 21

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #20)
> Dale is going to manually verify a backout of bug 956690. If it verifies,
> then we'll back that patch out.

Looks like Dale has left the work week, so I'm going to find someone else who can look into this.

Comment 22

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Jason Smith [:jsmith] from comment #21)
> (In reply to Jason Smith [:jsmith] from comment #20)
> > Dale is going to manually verify a backout of bug 956690. If it verifies,
> > then we'll back that patch out.
> 
> Looks like Dale has left the work week, so I'm going to find someone else
> who can look into this.

I tried to back out the mentionned bug locally and I still see the crash :/

Comment 23

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #22)
> (In reply to Jason Smith [:jsmith] from comment #21)
> > (In reply to Jason Smith [:jsmith] from comment #20)
> > > Dale is going to manually verify a backout of bug 956690. If it verifies,
> > > then we'll back that patch out.
> > 
> > Looks like Dale has left the work week, so I'm going to find someone else
> > who can look into this.
> 
> I tried to back out the mentionned bug locally and I still see the crash :/

Can't not reproduce if I turn off the HW composer. Will get a stack in a few.

Comment 24

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Sorry the stack is a bit small:

(gdb) bt
#0  0x42f04c38 in hwc_set (dev=0x40310840, dpy=<value optimized out>, sur=<value optimized out>, list=0x114)
    at hardware/qcom/display/libhwcomposer/a-family/hwcomposer.cpp:1789
#1  0x00000000 in ?? ()

Comment 25

[Milan Sreckovic [:milan] (needinfo for best results)]

Sotaro, your change in the this range is not the reason (I don't see how), but do you have any insight into when a HWC may crash as above, but the OGL compositing would work?  What should we be looking for? There were some layout/layer changes in the range, could it be that HWC doesn't like the type/number/whatever of layers we're sending it?  This is the range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bf49e4428906&tochange=6f544aa66c1a

Comment 26

[Sotaro Ikeda [:sotaro]]

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #24)
> Sorry the stack is a bit small:
> 
> (gdb) bt
> #0  0x42f04c38 in hwc_set (dev=0x40310840, dpy=<value optimized out>,
> sur=<value optimized out>, list=0x114)
>     at hardware/qcom/display/libhwcomposer/a-family/hwcomposer.cpp:1789
> #1  0x00000000 in ?? ()

On my master hamachi, after a backout of bug 956690, The STR in Comment 0 becomes difficult to reproduce, but the STR in Comment 2 still happens.

But I did not see the above hw composer's abort.

Comment 27

[Sotaro Ikeda [:sotaro]]

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #24)
> Sorry the stack is a bit small:
> 
> (gdb) bt
> #0  0x42f04c38 in hwc_set (dev=0x40310840, dpy=<value optimized out>,
> sur=<value optimized out>, list=0x114)
>     at hardware/qcom/display/libhwcomposer/a-family/hwcomposer.cpp:1789
> #1  0x00000000 in ?? ()

I never saw the abort around there. I feel that this abort is side effect of other problem. on my environment, hwcomposer.cpp:1789 is not set function, but drawLayerUsingBypass() function. The debug information seems not correct.

Comment 28

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #27)
> (In reply to Vivien Nicolas (:vingtetun) (:21) from comment #24)
> > Sorry the stack is a bit small:
> > 
> > (gdb) bt
> > #0  0x42f04c38 in hwc_set (dev=0x40310840, dpy=<value optimized out>,
> > sur=<value optimized out>, list=0x114)
> >     at hardware/qcom/display/libhwcomposer/a-family/hwcomposer.cpp:1789
> > #1  0x00000000 in ?? ()
> 
> I never saw the abort around there. I feel that this abort is side effect of
> other problem. on my environment, hwcomposer.cpp:1789 is not set function,
> but drawLayerUsingBypass() function. The debug information seems not correct.

sorry, my environment is master hamachi. The above might using other hardware.

Comment 29

[Sotaro Ikeda [:sotaro]]

I updated my master hamachi ROM from recent source code. By the ROM the crash does not happen by the STR in Comment 0 and the STR in Comment 2.

Comment 30

[Sotaro Ikeda [:sotaro]]

Recent change around APZ seems only Bug 968495. It changed apz.pan_repaint_interval from 250ms to 40 ms.

Comment 31

[Sotaro Ikeda [:sotaro]]

Can QA confirm if the problem happens on today(most recent) ROM?

Comment 32

[Sotaro Ikeda [:sotaro]]

Bug 968495 was just landed to m-c. Today's rom might not include the change.

Comment 33

[Tony Nguyen]

This issue is no longer present on today's Buri Master M-C build.

Environmental Variables:
Device: Buri Master M-C mozRIL
BuildID: 20140207040203
Gaia: 3fc26ae786e3869a7ef1e23afc9807ac1b4741f2
Gecko: d05c721ea1b0
Version: 30.0a1
v1.2-device.cfg