Closed Bug 1155854 Opened 9 years ago Closed 6 years ago

[Window Management][Edge Gesture] Edge gesturing quickly can cause icon screen to vertically draw and cause apps to force close

Categories

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v2.1 unaffected, b2g-v2.2 affected, b2g-master affected)

RESOLVED WONTFIX
Tracking Status
b2g-v2.1 --- unaffected
b2g-v2.2 --- affected
b2g-master --- affected

People

(Reporter: dharris, Unassigned)

References

()

Details

(Keywords: regression, Whiteboard: [3.0-Daily-Testing][systemsfe])

Attachments

(3 files)

Description:
Edge gesturing between apps is slow and can exhibit app closure. Also if the user is quickly edge gesturing between apps, there will be white icon screens drawing in vertically.


Repro Steps:
1) Update a Flame to 20150417010203
2) Open 2 apps (Clock, Messages, Video, Music, etc)
3) Edge gesture over to an app
4) Right when the icon screen goes away, edge gesture back


Actual:
Icon screen will draw in vertically, and close. Sometimes it will take a couple edge gestures for the app to close, but I have seen it on the first try on multiple occasions


Expected:
Edge gestures are handeld smoothly without app closure

Environmental Variables:
Device: Flame 3.0 (319mb)(Kitkat)(Full Flash)
Build ID: 20150417010203
Gaia: 3cd0a9facce26c2acc7be3755a17131a6358e33f
Gecko: 51e3cb11a258
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0


Repro frequency: 7/10 (Timing issue)
See attached: Logcat, Video - https://youtu.be/QjzGvsp4scg
This issue DOES occur on Flame 2.2

The Icon screen will draw in vertically and an app will force close

Environmental Variables:
Device: Flame 2.2 (319mb)(Kitkat)(Full Flash)
Build ID: 20150417002504
Gaia: d50b8a3919a7b4d8d289f150d3b9bed704ebafa9
Gecko: 5ebf32030512
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

=========================================================================================

This issue does NOT occur on Flame 2.1

The icon screen is brought to the forground smoothly and no apps will close

Environmental Variables:
Device: Flame 2.1 (319mb)(Kitkat)(Full Flash)
Build ID: 20150415001211
Gaia: bbe983b4e8bebfec26b3726b79568a22d667223c
Gecko: 3e3cbe35bce3
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 34.0 (2.1)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Functional regression causing apps to force close.

Requesting a window.
blocking-b2g: --- → 2.2?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
QA Contact: ktucker
Whiteboard: [3.0-Daily-Testing] → [3.0-Daily-Testing][systemsfe]
Regression.
Etienne, can you help out?
blocking-b2g: 2.2? → 2.2+
Flags: needinfo?(etienne)
QA Contact: ktucker → jmercado
The repro rate for this issue becomes too low to continue on a window the further you go back.  I thought I had it for a while but then I reproduced on a build after 57 attempts compared to recent builds which took at most 5 attempts, often on the first or second try.

Environmental Variables:
Device: Flame 3.0
BuildID: 20150202042034
Gaia: 4171327fce4803c52b2fae8071b114a70a3a68a7
Gecko: 3bf7ed413e87
Version: 38.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
(In reply to Gregor Wagner [:gwagner] from comment #3)
> Regression.
> Etienne, can you help out?

The application is just getting killed.
So we go back to the homescreen since this is what we do when the currently displayed app is killed.

Wonder if there's been changes with the LMK recently because it's not the first bug today which boils down to a low memory kill.
Flags: needinfo?(etienne)
In comment 4 it looks like we were trying to reproduce on a normal memory device. Let's try the regression window on a 319mb flame, and see if the repro rate is better.
The regression window in comment 4 was attempted on 319 memory.  Also this issue does NOT always lead to a close of the app, but it will still draw in vertically.
Ill take a look at this
Assignee: nobody → dale
So yeh this isnt a bug, its an app being force closed. As Etienne says it could be a change in LMK or just rising memory requirements as indicated in https://bugzilla.mozilla.org/show_bug.cgi?id=1155854#c4

Not sure what is actionable here, we have people tracking the memory requirements of the OS in general? or the media team for the video / music apps (they seem to be the biggest triggers).

Either way deassining, I dont think this is window management or sysfe particularly
Assignee: dale → nobody
Flags: needinfo?(anygregor)
Not blocking. Expected behavior for low memory devices.
blocking-b2g: 2.2+ → ---
Flags: needinfo?(anygregor)
Flags: needinfo?(nhirata.bugzilla)
Adding qawanted to check against 512MB and gather additional logs to show memory performance.
Keywords: qawanted
There's a rise in memory when you swipe to a different application.  I think that's what changed, due to the icons/screenshots taken when swiping.  You can see the rise when running adb shell b2g-procrank before an after a swipe.

Having said that, I cannot reproduce this bug using 512 mb of ram on the device, I can only reproduce the issue with 319 mb of memory
Flags: needinfo?(nhirata.bugzilla)
NI on Patrick Wang to take a look, it's only a low mem issue.
Flags: needinfo?(kk1fff)
I am looking at this bug.

Since I cannot reproduce with the build on 2.2 in comment #1, but if I delete /system/b2g/defaults/pref/lmk.js to let the LMK kill when there is more free memory, I see a similar symptom.

I need to have the low memory killer parameters. NI Derek for the output of b2g-info on the device.
Flags: needinfo?(kk1fff) → needinfo?(dharris)
Attached file B2G info Logcat
Attatched a logcat of the issue occuring on Flame 3.0 with 319mb memory

=================================================================================

I also tested this bug on Flame 3.0 with 512mb memory. I was able to get the apps to draw in vertically while edge gesturing, but I was not able to get apps to close like they do with 319mb memory

Environmental Variables:
Device: Flame 3.0 (512mb)(Kitkat)(Full Flash)
Build ID: 20150504010202
Gaia: e18cce173840d6ff07fb6f1f0e0ffb58b99aab3e
Gecko: dc5f85980a82
Gonk: a9f3f8fb8b0844724de32426b7bcc4e6dc4fa2ed
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0
Flags: needinfo?(dharris)
NI on Thinker to take a look.
Flags: needinfo?(tlee)
(In reply to Derek Harris [:DerekH] from comment #15)
> Created attachment 8600955 [details]
> B2G info Logcat
> 
> Attatched a logcat of the issue occuring on Flame 3.0 with 319mb memory
> 
Derek, this is adb logcat and doesn't contain b2g-info.

Please attach the output from the command: 'adb shell b2g-info'.
The output looks like this:

                          |     megabytes     |
           NAME  PID PPID CPU(s) NICE  USS  PSS  RSS SWAP VSIZE OOM_ADJ USER
            b2g  207    1  151.1    0 44.0 46.1 55.2 19.0 224.6       0 root
         (Nuwa)  463  207    0.9    0  0.0  0.9  7.2 10.4  64.9     -16 root
OperatorVariant 1057  463    0.7    0  0.0  1.1  7.8 10.2  70.2      11 u0_a1057
     Homescreen 1249  463   11.7    0  0.0  1.5  9.8 18.0  91.9       8 u0_a1249
          Music 1296  463   31.4    0 14.7 16.6 25.6  5.7 103.5       2 u0_a1296
          Video 1685  463   20.2    0  7.7  9.5 18.5  6.1  89.2      10 u0_a1685
 Find My Device 1943  463    1.1    0  1.2  2.9 11.1  8.5  68.7      11 u0_a1943
(Preallocated a 2811  463    0.5    0  2.8  3.9  9.1  6.6  68.7       1 u0_a2811

System memory info:

            Total 214.6 MB
        SwapTotal 192.0 MB
     Used - cache 164.5 MB
  B2G procs (PSS)  82.5 MB
    Non-B2G procs  82.1 MB
     Free + cache  50.1 MB
             Free  18.6 MB
            Cache  31.5 MB
         SwapFree 109.6 MB

Low-memory killer parameters:

  notify_trigger 9216 KB

  oom_adj min_free
        0  4096 KB
       58  5120 KB
      117  6144 KB
      352  7168 KB
      470  8192 KB
      588 10240 KB
root@flame:#
Flags: needinfo?(dharris)
(In reply to Cervantes Yu from comment #17)
> Derek, this is adb logcat and doesn't contain b2g-info.
> 
> Please attach the output from the command: 'adb shell b2g-info'.

Sorry, I misunderstood. I ran b2g-info and have attached it in a text file
Flags: needinfo?(dharris)
(In reply to Derek Harris [:DerekH] from comment #18)
> Created attachment 8601656 [details]
> b2g-info device snapshot
> 
I think this is the main reason why low memory kill happens in this bug:

  notify_trigger 14336 KB

  oom_adj min_free
        0  4096 KB
       58  5120 KB
      117  6144 KB
      352  7168 KB
      470  8192 KB
      588 20480 KB

Originally lmk.js lowers notify_trigger and the minfree for oom_adj 588 (please refer to the values in comment #17). It's then removed because it keeps too many apps around and the system will try very hard in swapping when the user opens many apps and then switches between them. The result is the device sometimes becomes very unresponsive if you open 5 or so apps.

Now we use the default values in b2g.js. It looks like the values make the LMK too aggressive to kill. The values need to be adjusted again. I guess the average of the 2 sets might work. We need more testing.
See Also: → 1081577
Derek handled the qawanted request for this issue in comment 15 and comment 18.
Flags: needinfo?(ktucker)
Keywords: qawanted
Flags: needinfo?(ktucker)
Flags: needinfo?(tlee)
Cervantes, could you let us know what type of testing you want us to do?  Are you asking for us to play with LMK values and test around that?  If so, could you provide a patch for the variations you want us to test?
Flags: needinfo?(cyu)
I just tested on my flame 319M and saw one force close after edge gesturing many times. From kernel dmesg, it's killed because of OOM.

I tend not to adjust the LMK values because changing the settings affects the behavior when the device runs short of memory. Tuning LMK settings doesn't solve the problem but only alleviates to some extent. Lowering the values definitely lowers the chance that apps are killed, but in exchange the system might become more unresponsive.

There are memory-shrinking bugs that once fixed, should help alleviate the symptom. One is bug 1155854, and another is 1166207. And to really fix this problem we may need to look at the timing of priority setting during edge gestures. Now I don't think I need QA to test against different LMK settings. Thanks Naoki.
Flags: needinfo?(cyu)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][qa-tracking]
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: