Closed Bug 811941 Opened 12 years ago Closed 12 years ago

b2g phone barely responsive (swipes take minutes to register) after tapping home when trying to launch an app

Categories

(Firefox OS Graveyard :: Gaia::Homescreen, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-basecamp:+)

RESOLVED FIXED
blocking-basecamp +

People

(Reporter: cww, Assigned: timdream)

Details

Attachments

(1 file)

Brand new phone from IT, freshly flashed.

Using the build from 11-07

Just in the process of setting it up, after about 30 minutes of use, the phone becomes completely unresponsive. This means swipes don't register for minutes at a time. It can even get stuck on the lock screen and I can't unlock it.

I can sometimes have even closed all of the running apps (except home screen of course) and it still gets stuck.  I'm pretty much 100% guaranteed to get it stuck within 30 minutes of hard-core playing with/setting up the phone.

Some common things:

1) I always set the time zone first and set up wireless.
2) I always try to set up email (hotmail). Sometimes this fails, sometimes not but that doesn't impact when it breaks.
3) I swipe around a lot so it's possibly related to swiping to everything.me
4) I often open clock and add an alarm
5) I almost always have brought up the task manager at least once and used to to close apps.

Some observations:

1) It seems related to the number of apps I've previously opened, even if I close them with the task manager (and hence gets stuck even with all the apps closed.)
2) Restart will make it responsive BUT it gets really bad very quickly. It's hardest to repro on a freshly flashed phone but gets progressively easier once it starts happening (even though I do power>restart every time it happens)
3) Fabrice thought it might be my particular device but I managed to make it happen with a brand new device from IT (took about 30 minutes) -- now it happens within 5 minutes of restarting on the new device and without having to open many apps.
4) Home button and power button still work (i.e. if you hold the home button it brings up the task switcher and if you hold the power button it brings up the power menu). Homescreen is the app that's freezing.
Just to be clear, my STRs on my current phone now that it's in this busted state:

Restart phone (power > restart).

Open email, wait for it to flash (after showing the screenshot).

Hit home

Hold home to bring up task manager

Swipe up on email to close it.

(This usually does it, otherwise repeat with a different app and at most two more times).

You have to do all of these things pretty quickly in succession. It seems harder to repro if I'm being very deliberate with my actions.
Ok, so I have 2 pages of notes from deliberately trying to repro this bug and timing my actions and I think everything I put in comment 1 is a lie.

REAL STRs (at least on a now-busted phone):

Open an app.

While it's still in "screenshot" mode, tap home. (Easiest to do with email, cost-control and settings).

You're busted.

I'm not convinced it was this easy to repro on a freshly-flashed phone so that still may be a factor.
Summary: b2g phone barely responsive (swipes take minutes to register) even with no apps running → b2g phone barely responsive (swipes take minutes to register) after tapping home when trying to launch an app
I just want to make sure. In 4) of #c1 you're saying at the end: "Homescreen is the app that's freezing". Do you mean you can swipe but it is very weird/slow?

Does this behavior get fixed if instead of swiping you try to open an application, wait for it to open and then close it?
You can swipe but it's very slow... and I mean you swipe, wait 4-5 minutes (not seconds) and it swipes (in like a couple stages).  

Nice catch with opening an application. It takes forever to load but if you wait for it and then close the application, it seems to restore the home screen to working.
(In reply to [:Cww] from comment #4)
> You can swipe but it's very slow... and I mean you swipe, wait 4-5 minutes
> (not seconds) and it swipes (in like a couple stages).  
> 
> Nice catch with opening an application. It takes forever to load but if you
> wait for it and then close the application, it seems to restore the home
> screen to working.

Thanks for trying. I believe the issue is with the visibility state of the homescreen. It is likely considered hidden so it is in a particular state. Tim I guess this is related to the transition work you're doing, assigning to you.


Also this is likely a blocker...
Assignee: nobody → timdream+bugs
blocking-basecamp: --- → ?
I think this is likely a Gecko bug if a swipe takes 4-5 minutes. Something is using the CPU, eating all the memory or constantly triggering GCs.... I noticed something similar after cancelling an automatic update but the swipe lag was about 4-5 seconds.
Can we get a profile and an about:memory dump, please?

The profiler is basically useless if we're spending our time in C++ (bug 810526), but I believe it can help us see if we're spinning in JS land (unlikely).

In order to get a useful profile, you need to do your own build and then run ./profile.sh from the root B2G directory.

An about:memory dump is easier; just run tools/get_about_memory.py (again from the root B2G directory; git clone git@github.com:mozilla-b2g/B2G.git) and attach the memory-reports file it creates.
Um, can I hand my phone to someone?
I feel like learning to use our most basic debugging tools is pretty helpful, particularly since, in your capacity as SUMO master, you may need to ask other people to use these same tools.

But if you want to drive up to NYC, I'll gladly pull the info off your phone.  :)
(In reply to [:Cww] from comment #8)
> Um, can I hand my phone to someone?

Are you in MV or SF?
Attached file Memory report
This is the memory report when we can't swipe any more.
In the main process

> 77.68 MB (100.0%) -- explicit
> ├──41.15 MB (52.97%) ── heap-unclassified

That's too high.  I'm working on tools to let us gain some insight into that, but it's going to take time; probably another week.

Maybe we're under memory pressure and gc'ing like crazy.  I think you should see notifications about memory pressure in logcat (subject GonkMemoryPressure).  Do you see anything interesting in there?
(In reply to Justin Lebar [:jlebar] from comment #12)
> In the main process
> 
> > 77.68 MB (100.0%) -- explicit
> > ├──41.15 MB (52.97%) ── heap-unclassified
> 
> That's too high.  I'm working on tools to let us gain some insight into
> that, but it's going to take time; probably another week.
> 
> Maybe we're under memory pressure and gc'ing like crazy.  I think you should
> see notifications about memory pressure in logcat (subject
> GonkMemoryPressure).  Do you see anything interesting in there?

This is from Cww's phone with a build from 2012-11-06. I am currently trying to reproduce this on current tip.
I installed an automatic update on his phone. Let's see if all the great work from last week will resolve this problem.
This sounds like one of the visibility/focus window manager bugs.
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
Whiteboard: dupeme
blocking-basecamp: ? → +
Opening apps has gotten a lot faster in the new build so I'm having a hard time reproducing this bug. It may be fixed.
Should we close this and just re-open if we can reproduce?  Can you reproduce it at all, Cheng?
Flags: needinfo?(cwwmozilla)
I can't repro anymore. I'm guessing we're good. Thanks.
Status: NEW → RESOLVED
Closed: 12 years ago
Flags: needinfo?(cwwmozilla)
Resolution: --- → FIXED
Component: General → Gaia::Homescreen
Whiteboard: dupeme
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: