If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[B2G][Usage App] Closing the Usage app is difficult

RESOLVED WONTFIX

Status

Firefox OS
Performance
P1
blocker
RESOLVED WONTFIX
3 years ago
3 years ago

People

(Reporter: Josh Schmitt [Joshs], Assigned: jhylands)

Tracking

({perf, regression})

unspecified
2.1 S1 (1aug)
ARM
Gonk (Firefox OS)
perf, regression

Firefox Tracking Flags

(b2g-v1.4 unaffected, b2g-v2.0 affected, b2g-v2.1 affected)

Details

(Whiteboard: [c=regression p=2 s= u=2.0] [273MB-Flame-Support])

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
Created attachment 8451916 [details]
log.txt

Description:
User is unable to exit or the performance while exiting is extremely slow.

Repro Steps:
1) Update a Flame to 20140707000200
2) Open the Usage app
3) Proceed through first time setup
4) Attempt to exit the Usage app

Actual:
The app takes a while to exit or does not exit at all.

Expected:
User can exit the Usage app and does so in a timely matter.

Environmental Variables:
Device: Flame 2.0
Build ID: 20140707000200
Gaia: ef67af27dff3130d41a9139d6ae7ed640c34d922
Gecko: f53099796238
Version: 32.0a2 (2.0)
Firmware Version: v122

User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Notes:
Repro frequency: 100%,
See attached: logcat
(Reporter)

Updated

3 years ago
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
QAWanted for the other Flame branch checks to see if this is a regression.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: qawanted
This bug repro's on: Flame 2.1 Master, Flame 2.0

Actual Results: With Mem set to 273, Going through Setup of the Usage app then trying to exit causes a failure to exit the app.

Environmental Variables:
Device: Flame Master
Build ID: 20140708201331
Gaia: 0f9f11d0a6dadb3ea27160204bbe911c1ad69a6f
Gecko: 196d05832e12
Version: 33.0a1 (Master)
Firmware Version: v122
-----------------------------------------------
Environmental Variables:
Device: Flame 2.0
Build ID: 20140708163231
Gaia: 1dd043857399c713e3b509c0ed31bdf20326f08b
Gecko: 0b5f757da75a
Version: 32.0a2 (2.0)
Firmware Version: v122

-----------------------------------------------
-----------------------------------------------

This bug does NOT repro on: Flame 1.4

Actual Result: At 273mb, no problems are seen when trying to exit the Usage app. App exits fine.

Environmental Variables:
Device: Flame 1.4
Build ID: 20140708070432
Gaia: 229864ff4ad90899f017341b9e81ed0b53498c66
Gecko: 7e146a1d7542
Version: 30.0 (1.4)
Firmware Version: v122
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v1.4: --- → unaffected
status-b2g-v2.1: --- → affected
Flags: needinfo?(jmitchell)
Keywords: qawanted → regression
QA Contact: croesch
nomming as a blocker - issue is very severe
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: perf, regressionwindow-wanted
Priority: -- → P1
Whiteboard: [273MB-Flame-Support] → [273MB-Flame-Support][c=regression p= s= u=]
Triage: Can you please attach a video of your steps to reproduce? How are you exiting the app, by pushing the home button? Thanks!
Flags: needinfo?(jschmitt)
Switching to qawanted to address comment 4.
Keywords: regressionwindow-wanted → qawanted
Video Link
http://youtu.be/pJqFi2dO7AM

Simply trying to press the Home button to exit the app does not always work. Also the user does not have to go through the setup process. This video is just from opening the app from a new instance because the setup attempt did not produce the bug and I exited fine.

Updated Steps:
1. Launch Usage app.
2. Tap the home button to exit the app.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Repro rate from 7/8 build is about 80%.

However!

With the latest 2.1 build 7/9 this issue does not seem to occur I notice a lot of lag when it tries to close but, I'm able to exit the Usage app. May be a little laggy but not like yesterdays build.

Build info for today's build 7/9
Environmental Variables:
Device: Flame Master
Build ID: 20140709070635
Gaia: c394b7b4205b6f1a6ca44915fc08650f3ad127ec
Gecko: 2d88803a0b9c
Version: 33.0a1 (Master)
Firmware Version: v122
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: regressionwindow-wanted
QA Contact: croesch → jmercado
triage: per comment 7, let's keep the nomination for now.
Tested bug and I can't reproduce it.
 Hamachi 
2.0
Gecko-60aa130
Gaia-29b7871
(In reply to Loli from comment #9)
> Tested bug and I can't reproduce it.
>  Hamachi 
> 2.0
> Gecko-60aa130
> Gaia-29b7871

This needs to be tested on Flame 273 MB. Buri won't be a valid low memory environment to use here given that it's not the chipset we are supporting this release.
(In reply to Cody Roesch [:croesch] from comment #7)
> Repro rate from 7/8 build is about 80%.
> 
> However!
> 
> With the latest 2.1 build 7/9 this issue does not seem to occur I notice a
> lot of lag when it tries to close but, I'm able to exit the Usage app. May
> be a little laggy but not like yesterdays build.
> 
> Build info for today's build 7/9
> Environmental Variables:
> Device: Flame Master
> Build ID: 20140709070635
> Gaia: c394b7b4205b6f1a6ca44915fc08650f3ad127ec
> Gecko: 2d88803a0b9c
> Version: 33.0a1 (Master)
> Firmware Version: v122

Triage is royally confused by the above comment. Can we please get a reproduction rate again on 2.0 & 2.1 on the latest builds for the bug as filed?
Keywords: regressionwindow-wanted → qawanted
On the latest Central engineering builds the issue does reproduce but at a lesser severity than previously seen.  Where before it would take 10 seconds or more to close the usage app, if ever, now it takes about 3 seconds to close and about another second to be able to interact with the homescreen again.

Environmental Variables:
Device: Flame Master
BuildID: 20140710071153
Gaia: 09642e74e250fbc62db860c808ef188628fca55d
Gecko: f93c0ef45597
Version: 33.0a1 (Master) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Jayme - Jason asked for a check of the latest 2.0 and 2.1, you only gave the information for 2.1; please complete the QA-Wanted request.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell) → needinfo?(jmercado)
Keywords: qawanted
On the latest 2.0 this issue still reproduces as written.  The app will not close.

Environmental Variables:
Device: Flame 2.0
BuildID: 20140710065452
Gaia: 35a9b715e7348ec738ff6c8a59f50190390a06f2
Gecko: 9297a56e155e
Version: 32.0a2 (2.0) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmercado) → needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
(Reporter)

Comment 15

3 years ago
(In reply to Mason Chang [:mchang] from comment #4)
> Triage: Can you please attach a video of your steps to reproduce? How are
> you exiting the app, by pushing the home button? Thanks!

Comment 6 answered the NI on me, removing my NI.
Flags: needinfo?(jschmitt)
:mlee, can you get someone to help diagnose this issue ? Jsmith mentioned he's seen this across app's with low memory config .
blocking-b2g: 2.0? → 2.0+
Flags: needinfo?(mlee)

Updated

3 years ago
Component: Gaia::Cost Control → Performance

Updated

3 years ago
QA Whiteboard: [QAnalyst-Triage+]
Keywords: regressionwindow-wanted

Comment 17

3 years ago
Ting-yu, can you take a look on this bug? Thanks.
Flags: needinfo?(tchou)
Sure, but according to the video of comment 6 and comment 16, seems this bug is about how fast can Flame switch from app to homescreen, is my understanding correct?
Flags: needinfo?(tchou)
Is this happening for other apps? Is Usage the only one affected?

Updated

3 years ago
Assignee: nobody → tchou
Status: NEW → ASSIGNED
Flags: needinfo?(mlee)
Whiteboard: [273MB-Flame-Support][c=regression p= s= u=] → [c=regression p= s= u=2.-] [273MB-Flame-Support]

Updated

3 years ago
Whiteboard: [c=regression p= s= u=2.-] [273MB-Flame-Support] → [c=regression p= s= u=2.0] [273MB-Flame-Support]
B2g-inbound Regression Window

Last working 
Environmental Variables:
Device: Flame Master
BuildID: 20140604084216
Gaia: 2a4c7becdb141d2601e47a040a27eebe52a8db79
Gecko: fd5bb34861d6
Version: 32.0a1 (Master) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0


First Broken 
Environmental Variables:
Device: Flame Master
BuildID: 20140604105916
Gaia: 18e2e8dc2d9ff19cd1210026367c14956d04eb0d
Gecko: c36c5f011229
Version: 32.0a1 (Master) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0


Last working gaia / First broken gecko - Issue does NOT occur
Gaia: 2a4c7becdb141d2601e47a040a27eebe52a8db79
Gecko: c36c5f011229

First broken gaia / Last working gecko - Issue DOES occur
Gaia: 18e2e8dc2d9ff19cd1210026367c14956d04eb0d
Gecko: fd5bb34861d6

Gaia Pushlog:  https://github.com/mozilla-b2g/gaia/compare/2a4c7becdb141d2601e47a040a27eebe52a8db79...18e2e8dc2d9ff19cd1210026367c14956d04eb0d
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: regressionwindow-wanted
"Enable vertical homescreen" is in that range.

Updated

3 years ago
Severity: normal → blocker
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #21)
> "Enable vertical homescreen" is in that range.

Not only that, but there does not seem to be any bugs in that pushlog that would affect the usage app.

Kevin - this is not the first time I've NI'd you recently with regression-range results indicating the first vertical homescreen build as the culprit (first broken) - could there be some larger issue at play? It seems like these 273 mem bugs are not true regressions of broken features but just things going 'wonky' because there is less free memory once Vertical Homescreen is added?  I'm just asking because it feels odd to push so many of the same regression-window results at you.
Flags: needinfo?(jmitchell) → needinfo?(kgrandon)
Joshua, the vertical home screen is known to significantly increase memory usage.  See Bug 1029902 and related issues.
Flags: needinfo?(kgrandon)
Well, the homescreen is currently using more memory, but we are going to fix that. In the meantime it seems that the increased memory usage is unveiling system/platform bugs. It's unlikely that the homescreen is the culprit, but we should certainly fix these problems when there is increased memory load.
Well, there does not seem to be anything specific about the usage app in the pushlog; so I don't have anything to nominate as the 'broken by'.

Flipping QA-Triage flag to +
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Unassign myself as Bhavana would like me to look into bug 1038854, which has higher priority. I will come back later if no one takes this.
Assignee: tchou → nobody
Status: ASSIGNED → NEW
When Homescreen gets killed by LMK:

  a. before pressing Home key (when Usage is in foreground)
  b. after pressing Home key (while switching from Usage to Homescreen)

the switching takes longer as it needs to relaunch Homescreen, and there will be a short period only wallpaper is shown. I also noticed that when Homescreen moves to OOM_ADJ 2, Usage does not change from 2 to 6 right away, probably this is the reason why b) is happening.

BTW, "Non-B2G procs" of b2g-info looks high:

                           |     megabytes     |
           NAME   PID PPID CPU(s) NICE  USS  PSS  RSS VSIZE OOM_ADJ USER     
            b2g   326    1  264.6    0 19.9 22.6 27.3 211.4       0 root     
         (Nuwa)   892  326    3.1    0  0.2  0.4  0.8  53.7       0 root     
          Usage 13786  892   29.5    1 12.4 16.0 21.5 105.0       2 u0_a13786
(Preallocated a 15003  892    0.6   18  7.7 10.5 15.3  59.7       1 u0_a15003

System memory info:

            Total 167.8 MB
     Used - cache 142.2 MB
  B2G procs (PSS)  49.5 MB
    Non-B2G procs  92.7 MB
     Free + cache  25.6 MB
             Free   6.8 MB
            Cache  18.9 MB

I will try to figure out where is the number from.
(Assignee)

Comment 28

3 years ago
I'm taking this to do a bisect, will re-assign once I have a specific commit at fault.
Assignee: nobody → jhylands
(Assignee)

Updated

3 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

3 years ago
Whiteboard: [c=regression p= s= u=2.0] [273MB-Flame-Support] → [c=regression p=2 s= u=2.0] [273MB-Flame-Support]
Flagging qawanted for a 319 MB Flame check.
QA Whiteboard: [QAnalyst-Triage+]
Keywords: qawanted
This issue no longer reproduces when the devices is running 319 MB.  Also the repro rate is significantly reduced on 273 MB

Environmental Variables:
Device: Flame 2.0
BuildID: 20140724190006
Gaia: 9b6d7357031f2412b18a2fb140d5c974842d4393
Gecko: fbb3b8be8f6c
Version: 32.0 (2.0) 
Firmware Version: v121-2
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
no repro in the new 319 mem, unblocking but leaving open for perf investigation
blocking-b2g: 2.0+ → ---
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)

Updated

3 years ago
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
(Assignee)

Comment 32

3 years ago
We're going to close this as wont-fix.
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX

Updated

3 years ago
Target Milestone: --- → 2.1 S1 (1aug)
You need to log in before you can comment on or make changes to this bug.