Closed
Bug 1037627
Opened 10 years ago
Closed 10 years ago
[B2G][Marketplace] Multiple apps will experience LMK when the device is put into sleep mode after the app launches.
Categories
(Firefox OS Graveyard :: Performance, defect, P1)
Tracking
(b2g-v1.4 unaffected, b2g-v2.0 affected, b2g-v2.1 affected)
RESOLVED
WONTFIX
2.1 S1 (1aug)
Tracking | Status | |
---|---|---|
b2g-v1.4 | --- | unaffected |
b2g-v2.0 | --- | affected |
b2g-v2.1 | --- | affected |
People
(Reporter: dgomez, Assigned: huseby)
References
()
Details
(Keywords: memory-footprint, perf, regression, Whiteboard: [273MB-Flame-Support], [2.0-exploratory] [MemShrink:P2][c=memory p=4 s= u=2.0])
Attachments
(3 files)
Description:
When a user launches an installed Marketplace app (confirmed to happen with Youtube, Facebook, ConnectA2, CutTheRope, and Interactive Firefox Logo app), puts their device into sleep mode for about 15 - 20 seconds, and wakes up their device, the launched app will have crashed. The user must restart the app in order to get back into it.
Prerequisites: Be connected to the internet via WiFi.
Repro Steps:
1) Update a Flame to 20140711000201
2) Launch the Marketplace app.
3) Download Youtube, Facebook, ConnectA2, CutTheRope, or Interactive Firefox Logo app
4) Launch the downloaded app.
5) Once the app is loaded, put the device into sleep mode by pressing the power button.
6) Wait about 20 seconds and press the power button again to wake the device.
7) Observe the screen.
Actual:
The launched app will experience an OOM, LMK.
Expected:
The launched app will remain on the screen.
2.0 Environmental Variables:
Device: Flame 2.0 (273MB)
BuildID: 20140711000201
Gaia: 18c44a1bc31b374ba00a069904465a8d07971a60
Gecko: f880dae4fdbe
Version: 32.0a2 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Repro frequency: 4/4 - 100%
See attached: Logcat_Marketplace_OOM.txt, Video: http://youtu.be/AMYOw4t6gMA
Reporter | ||
Comment 1•10 years ago
|
||
This issue DOES occur on Flame 2.1 (273MB).
Flame 2.1 (273MB)
2.1 Environmental Variables:
Device: Flame Master
Build ID: 20140711040202
Gaia: c47094a26c87ba71a3da4bae54febd0da21f3393
Gecko: 1b1296d00330
Version: 33.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0
Result: The app the user had launched is LMKed.
-------------------------------------------------------------------------------------------------------
This issue DOES NOT occur on Flame 2.0 (512MB), Flame 1.4 (273MB), Buri 2.0, Buri 2.1, Buri 1.4, Open_C 2.0, Open_C 1.4, Open_C 2.1, Flame Base v122 (273MB), and Flame Base v121-2 (273MB).
Flame 2.0 (512mb)
2.0 Environmental Variables:
Device: Flame 2.0
BuildID: 20140711000201
Gaia: 18c44a1bc31b374ba00a069904465a8d07971a60
Gecko: f880dae4fdbe
Version: 32.0a2 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Flame 1.4 (273MB)
1.4 Environmental Variables:
Device: Flame 1.4
Build ID: 20140711000202
Gaia: e273c1f52ed7187e4e0b2d66ed5718f0f20c6eeb
Gecko: 896fa800b72d
Version: 30.0 (1.4)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
Buri 2.1
2.1 Environmental Variables:
Device: Buri Master
Build ID: 20140711040202
Gaia: c47094a26c87ba71a3da4bae54febd0da21f3393
Gecko: 1b1296d00330
Version: 33.0a1 (Master) MOZ
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0
Buri 2.0
2.0 Environmental Variables:
Device: Buri 2.0
Build ID: 20140711000201
Gaia: 18c44a1bc31b374ba00a069904465a8d07971a60
Gecko: f880dae4fdbe
Version: 32.0a2 (2.0)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Buri 1.4
1.4 Environmental Variables:
Device: Buri 1.4
Build ID: 20140711000202
Gaia: e273c1f52ed7187e4e0b2d66ed5718f0f20c6eeb
Gecko: 896fa800b72d
Version: 30.0 (1.4) MOZ
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
Open_C 2.1
2.1 Environmental Variables:
Device: Open_C Master
Build ID: 20140711040202
Gaia: c47094a26c87ba71a3da4bae54febd0da21f3393
Gecko: 1b1296d00330
Version: 33.0a1 (Master)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0
Open_C 2.0
2.0 Environmental Variables:
Device: Open_C 2.0
Build ID: 20140711000201
Gaia: 18c44a1bc31b374ba00a069904465a8d07971a60
Gecko: f880dae4fdbe
Version: 32.0a2 (2.0)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Open_C 1.4
1.4 Environmental Variables:
Device: Open_C 1.4
Build ID: 20140711000202
Gaia: e273c1f52ed7187e4e0b2d66ed5718f0f20c6eeb
Gecko: 896fa800b72d
Version: 30.0 (1.4)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
Flame Base v122 (273MB)
Base v122 Environmental Variables:
Device: Flame 1.3
Build ID: 20140616171114
Gaia: e1b7152715072d27e0880cdc6b637f82fa42bf4e
Gecko: e181a36ebafaa24e5390db9f597313406edfc794
Version: 28.0 (1.3)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:28.0) Gecko/28.0 Firefox/28.0
Flame Base v121-2 (273MB)
Base v121-2 Environmental Variables:
Device: Flame 1.3
Build ID: 20140610200025
Gaia: e106a3f4a14eb8d4e10348efac7ae6dea2c24657
Gecko: b637b0677e15318dcce703f0358b397e09b018af
Version: 28.0 (1.3)
Firmware Version: v121-2
User Agent: Mozilla/5.0 (Mobile; rv:28.0) Gecko/28.0 Firefox/28.0
Actual Result: The user is taken back to the app that was launched earlier.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Updated•10 years ago
|
Component: General → Performance
Product: Marketplace → Firefox OS
Version: Avenir → unspecified
Updated•10 years ago
|
Comment 2•10 years ago
|
||
Dean can you flip the tracking flags according to your results?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage-]
Flags: needinfo?(pbylenga) → needinfo?(dgomez)
Reporter | ||
Comment 3•10 years ago
|
||
Updating tracking flags.
I could not set tracking flags earlier due to the Product being set to Marketplace.
QA Whiteboard: [QAnalyst-Triage-] → [QAnalyst-Triage?]
status-b2g-v1.4:
--- → unaffected
status-b2g-v2.0:
--- → affected
status-b2g-v2.1:
--- → affected
Flags: needinfo?(dgomez) → needinfo?(pbylenga)
Comment 4•10 years ago
|
||
Nominating to block 2.0, is a regression from 1.4 at 273MB and affects multiple apps. Requesting a window.
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: regressionwindow-wanted
Updated•10 years ago
|
Priority: -- → P2
Whiteboard: [273MB-Flame-Support], [2.0-exploratory] [MemShrink] → [273MB-Flame-Support], [2.0-exploratory] [MemShrink][c=memory p= s= u=]
Updated•10 years ago
|
blocking-b2g: 2.0? → 2.0+
Updated•10 years ago
|
Severity: normal → blocker
Priority: P2 → P1
Whiteboard: [273MB-Flame-Support], [2.0-exploratory] [MemShrink][c=memory p= s= u=] → [273MB-Flame-Support], [2.0-exploratory] [MemShrink][c=memory p= s= u=2.0]
Assignee | ||
Comment 5•10 years ago
|
||
This is a problem due to memory pressure. Since the homescreen memory usage issues tracked by Bug 1029902 are the highest priority at the moment, we want to re-test this after Bug 1029902 is resolved. For now we'll just block on that and see if this goes away when homescreen uses less memory.
Depends on: 1029902
Comment 6•10 years ago
|
||
This needs to be resolve regardless of homescreen memory pressure. This is a race condition in the system app. The homescreen should OOM and we should be able to re-launch it.
We are going to improve the homescreen soon, but I fear that is just going to mask the real problem.
No longer depends on: 1029902
Updated•10 years ago
|
QA Contact: ckreinbring
Assignee | ||
Comment 7•10 years ago
|
||
After talking with :kgrandon, we decided that this shouldn't wait for the homescreen memory issues to be fixed before investigating/addressing this one.
Assignee: nobody → dhuseby
Assignee | ||
Updated•10 years ago
|
Whiteboard: [273MB-Flame-Support], [2.0-exploratory] [MemShrink][c=memory p= s= u=2.0] → [273MB-Flame-Support], [2.0-exploratory] [MemShrink][c=memory p=4 s= u=2.0]
Comment 8•10 years ago
|
||
Regression window:
Last working
Build ID: 20140604142816
Gaia: a38a6a5c6fabc97dd16d5360632b5ac5c7e06241
Gecko: 951e3a671279
Platform Version: 32.0a1
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
First broken
Build ID: 20140604173717
Gaia: d2cfef555dabab415085e548ed44c48a99be5c32
Gecko: 2ebadbba6cc8
Platform Version: 32.0a1
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Working Gaia / Broken Gecko = No repro
Broken Gaia / Working Gecko = Repro
Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/a38a6a5c6fabc97dd16d5360632b5ac5c7e06241...d2cfef555dabab415085e548ed44c48a99be5c32
B2G Inbound
Last working
Build ID: 20140604084216
Gaia: 2a4c7becdb141d2601e47a040a27eebe52a8db79
Gecko: fd5bb34861d6
Platform Version: 32.0a1
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
First broken
Build ID: 20140604105916
Gaia: 18e2e8dc2d9ff19cd1210026367c14956d04eb0d
Gecko: c36c5f011229
Platform Version: 32.0a1
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Working Gaia / Broken Gecko = No repro
Broken Gaia / Working Gecko = Repro
Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/2a4c7becdb141d2601e47a040a27eebe52a8db79...18e2e8dc2d9ff19cd1210026367c14956d04eb0d
Comment 9•10 years ago
|
||
Another pushlog pointing to the first vertical homescreen build as the cause.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Comment 10•10 years ago
|
||
We've already encountered a similar issue on the Tarako. The issue there was triggered by the natural lack of free memory rather than the homescreen regression we had here but the root cause is the same once memory starts to get low. For a description of the issue you can read bug 989713 comment 72. Long story short, when turning off the screen the foreground's application priority drops below the priority of the homescreen. If we're tight on memory this will cause the said app to be reaped by the LMK. I had a fix for this in attachment 8423464 [details] [diff] [review] but I refrained from landing it at the time. The reason we didn't take it was that this would change the current behavior of the process priority manager significantly when dealing with FG/BG transitions and this requires large changes to the existing tests as well as further coverage, and also could induce startup time regressions when the phone is loaded. Since I didn't have enough time to do extensive testing we decided not to pick it up. If having a fix for this particular scenario is important however I should have enough time next week for finishing it up.
Assignee | ||
Comment 11•10 years ago
|
||
I can confirm that the oom kill is happening on my flame flashed with v122+fonts plus gecko+gaia build ID 20140711000201. it took considerably longer than 20 seconds for the oom kill to happen. The log shows these oom kill events:
E/OomLogger( 333): [Kill]: send sigkill to 2431 (Marketplace), adj 667, size 4667
E/OomLogger( 333): [Kill]: send sigkill to 3000 (Facebook), adj 667, size 5472
E/OomLogger( 333): [Kill]: send sigkill to 3133 (YouTube), adj 667, size 4879
Assignee | ||
Comment 12•10 years ago
|
||
This is a memory report gathered on a v2.0 flame that is in sleep mode, just before oom killing the twitter app that was running when the device went to sleep.
If I'm reading this memory report correctly, at the bottom of the memory report, I'm seeing the following:
168 MB for b2g+child processes
85 MB for system processes
+ 11 MV for zram-compr-data-size
---------------------------------
264 MB total
That's going to cause the memory pressure event that is oom killing the twitter app.
Assignee | ||
Comment 13•10 years ago
|
||
This is the memory report with the twitter app running before the device goes to sleep. Unfortunately, this doesn't look much different than when the device is asleep, just before oom killing the twitter app.
Hrm....
Assignee | ||
Comment 14•10 years ago
|
||
i just caught the system oom killing the twitter app with this message:
E/OomLogger( 3959): [Kill]: gtp_init_ext_watchdog i2c_transfer send sigkill to 4394 (Twitter), adj 667, size 5939
so the gtp_init_ext_watchdog is in the gt9xx.c touchscreen driver. is this log error saying that the touchscreen event processing caused the oom kill?
Assignee | ||
Comment 15•10 years ago
|
||
Kyle,
is the oom kill log message in Comment 14 show that the cause is touch event processing? the gtp_init_ext_watchdog is associated with the touch screen device.
Flags: needinfo?(khuey)
I've never seen it with something else in there before. Maybe dhylands knows?
Flags: needinfo?(khuey) → needinfo?(dhylands)
Updated•10 years ago
|
Whiteboard: [273MB-Flame-Support], [2.0-exploratory] [MemShrink][c=memory p=4 s= u=2.0] → [273MB-Flame-Support], [2.0-exploratory] [MemShrink:P2][c=memory p=4 s= u=2.0]
Comment 17•10 years ago
|
||
It's entirely possible that the gt9xx driver is trying to do a memory allocation.
If no memory is available, then this will trigger an OOM and one of the child processes will be killed.
Flags: needinfo?(dhylands)
Comment 18•10 years ago
|
||
It's also possible that it has nothing to do with the gt9xx driver and that it was just in the middle of printing something, got context switched away to something else which tried to allocate and caused the OOM.
Comment 19•10 years ago
|
||
(In reply to Dave Hylands [:dhylands][on PTO Wed Jul 23] from comment #17)
> It's entirely possible that the gt9xx driver is trying to do a memory
> allocation.
Since the LMK is triggered by any VM activity then it could be anything touching some space that wasn't previously backed by physical memory at that moment. gtp_init_ext_watchdog() doesn't seem to be doing allocations on its own but it could really be just touching some clean pages and thus triggering the LMK. Unless it's repeatable I wouldn't read too much into it, I don't think that particular function call is responsible for the lack of free memory.
Assignee | ||
Comment 20•10 years ago
|
||
IIRC, I saw it multiple times. That was two days ago. Let me see if it happens again.
Comment 21•10 years ago
|
||
QA Wanted to retest on 319 MB Flame.
QA Whiteboard: [QAnalyst-Triage+]
Keywords: qawanted
Updated•10 years ago
|
QA Contact: ckreinbring → jmitchell
Comment 22•10 years ago
|
||
Issue does NOT repro on 2.0 or 2.1 flame in 319 mb mem
Actual Results - The launched apps remain on the screen when the device is unlocked
Device: Flame Master (319 mem)
Build ID: 20140725102306
Gaia: 3a06aa58245eaf848242d6d1497c1af536fffabd
Gecko: 8da875b402fe
Version: 34.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Device: Flame 2.0 (319 mem)
Build ID: 20140721082721
Gaia: b9d19011123487009c80d1200937652d58c434a0
Gecko: d69cd84b6824
Version: 32.0a2 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Comment 23•10 years ago
|
||
issue does not repro in 319 mem, removing blocking flag but leaving open for perf investigation
blocking-b2g: 2.0+ → ---
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
Assignee | ||
Comment 24•10 years ago
|
||
Since this bug is not longer blocking 2.0 due to not being able to reproduce on the new 319MB minimum RAM spec, I'm closing it as won't fix.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
Updated•10 years ago
|
Target Milestone: --- → 2.1 S1 (1aug)
You need to log in
before you can comment on or make changes to this bug.
Description
•