Created attachment 8594151 [details] Vertical draw and closure Logcat 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?]
Functional regression causing apps to force close. Requesting a window.
blocking-b2g: --- → 2.2?
QA Whiteboard: [QAnalyst-Triage?]
Whiteboard: [3.0-Daily-Testing] → [3.0-Daily-Testing][systemsfe]
Regression. Etienne, can you help out?
blocking-b2g: 2.2? → 2.2+
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?]
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
(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.
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
Not blocking. Expected behavior for low memory devices.
blocking-b2g: 2.2+ → ---
Adding qawanted to check against 512MB and gather additional logs to show memory performance.
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
NI on Patrick Wang to take a look, it's only a low mem issue.
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)
Created attachment 8600955 [details] 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
NI on Thinker to take a look.
(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:#
Created attachment 8601656 [details] b2g-info device snapshot (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
(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: → bug 1081577
Derek handled the qawanted request for this issue in comment 15 and comment 18.
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?
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.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][qa-tracking]
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 20 days ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.