Closed
Bug 1037050
Opened 10 years ago
Closed 10 years ago
[B2G][Dialer] Launched app are killed if the user is in an incoming call and ends the call after 20 seconds.
Categories
(Firefox OS Graveyard :: Performance, defect, P1)
Tracking
(b2g-v1.4 unaffected, b2g-v2.0 affected, b2g-v2.1 unaffected)
RESOLVED
WONTFIX
2.1 S1 (1aug)
Tracking | Status | |
---|---|---|
b2g-v1.4 | --- | unaffected |
b2g-v2.0 | --- | affected |
b2g-v2.1 | --- | unaffected |
People
(Reporter: dgomez, Unassigned)
References
()
Details
(Keywords: memory-footprint, perf, regression, Whiteboard: [273MB-Flame-Support], [2.0-exploratory] [MemShrink:P2][c=memory p= s= u=2.0])
Attachments
(2 files)
Description:
When a user launches an app from the homescreen (confirmed to occur with Calendar, FM Radio, Clock, and Youtube app), accepts an incoming call, and the user hangs up the call after 20 seconds, the user will return to the homescreen with the app they were just in having crashed.
Prerequisites: Have an extra device to call the device under test (DUT).
Repro Steps:
1) Update a Flame to 20140708000322
2) Launch the the Calendar, FM Radio, or Clock.
3) Have the second device call the DUT.
4) Accept the phone call and wait until 21 seconds have passed.
5) On the DUT, end the call by pressing the red 'end call' button.
6) Observe the screen as the call ends.
Actual:
The app the user was in crashes and the user must relaunch it.
Expected:
The user is taken back to the app that they were originally in before the call took place.
2.0 Environmental Variables:
Device: Flame 2.0 (273MB)
BuildID: 20140708000322
Gaia: e935f4ff190b76c70d9b2af8856c542a6e4a7546
Gecko: 3f9d7a3a0b7b
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: 5/5 - 100%
See attached: Logcat_Call_App_Crash.txt, Video: http://youtu.be/FekysRdbaEA
Reporter | ||
Comment 1•10 years ago
|
||
This issue DOES NOT occur on Flame 2.0 (512MB), Flame 2.1 (273MB), 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.
Flame 2.0 (512mb)
2.0 Environmental Variables:
Device: Flame 2.0
BuildID: 20140708000322
Gaia: e935f4ff190b76c70d9b2af8856c542a6e4a7546
Gecko: 3f9d7a3a0b7b
Version: 32.0a2 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Flame 2.1 (273MB)
2.1 Environmental Variables:
Device: Flame Master
BuildID: 20140709040203
Gaia: 0f9f11d0a6dadb3ea27160204bbe911c1ad69a6f
Gecko: 196d05832e12
Version: 33.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0
Flame 1.4 (273MB)
1.4 Environmental Variables:
Device: Flame 1.4
Build ID: 20140709003002
Gaia: b0e9b4bdb39c5eb93a6783a34624ffc84f62b126
Gecko: acf704e54e19
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: 20140709073020
Gaia: c394b7b4205b6f1a6ca44915fc08650f3ad127ec
Gecko: 2d88803a0b9c
Version: 33.0a1 (Master)
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: 20140709063007
Gaia: 1774027323bb072b4ebdfea9883572bcf2535c87
Gecko: 11b6493a7d8f
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: 20140709003002
Gaia: b0e9b4bdb39c5eb93a6783a34624ffc84f62b126
Gecko: acf704e54e19
Version: 30.0 (1.4)
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: 20140708040218
Gaia: 740faa5d0060fb218b407cf224330654ddf833a5
Gecko: 465280604ea6
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: 20140708000322
Gaia: e935f4ff190b76c70d9b2af8856c542a6e4a7546
Gecko: 3f9d7a3a0b7b
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: 20140709000201
Gaia: b0e9b4bdb39c5eb93a6783a34624ffc84f62b126
Gecko: acf704e54e19
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 returned to their previous app as expected without it crashing.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Comment 2•10 years ago
|
||
This is a regression from 1.4 and undesired behavior. This will frustrate the end user often if they have to relaunch their previously opened app every time they receive a phone call. Nominating this issue 2.0?
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: regressionwindow-wanted
Updated•10 years ago
|
Updated•10 years ago
|
blocking-b2g: 2.0? → 2.0+
Looking at the log, it doesn't look like it crashed; it looks like the apps were killed because of low memory or OOM:
07-09 16:19:59.651 288 288 E OomLogger: [Kill]: send sigkill to 6520 (Clock), adj 667, size 3595
Summary: [B2G][Dialer] Launched app crashes if the user is in an incoming call and ends the call after 20 seconds. → [B2G][Dialer] Launched app are killed if the user is in an incoming call and ends the call after 20 seconds.
Comment 4•10 years ago
|
||
Thinker, do you have any suggestion on this bug? Thanks.
Flags: needinfo?(tlee)
Comment 5•10 years ago
|
||
Hi, Ting-Yuan, can you help to take a look on this bug? Thanks.
Flags: needinfo?(thuang)
Updated•10 years ago
|
Flags: needinfo?(tlee)
Updated•10 years ago
|
Assignee: nobody → thuang
Status: NEW → ASSIGNED
Flags: needinfo?(thuang)
Comment 6•10 years ago
|
||
The physical memory available to userspace is 167.8MB which is tight. (There are 176.7MB on ZTE Open.) I also came across with this problem on v2.1 when running larger applications such as settings and facebook. v1.4 don't incur the problem because it is slimmer.
After comparing the memory allocated by processes between v1.4, v2.0 and v2.1, the most noticeable change is in homescreen. Please refer to the attachment for detailed memory reports.
v1.4:
| megabytes |
NAME PID PPID CPU(s) NICE USS PSS RSS SWAP VSIZE OOM_ADJ USER
b2g 308 1 31.2 0 39.4 42.0 49.2 7.5 153.7 0 root
(Nuwa) 830 308 1.5 0 0.3 1.7 6.8 6.7 52.2 0 root
Homescreen 965 830 5.3 18 11.3 14.3 23.0 3.2 75.4 8 u0_a965
Clock 1125 830 2.7 18 8.9 12.6 22.0 2.0 67.4 10 u0_a1125
(Preallocated a 1146 830 0.7 18 4.6 7.2 14.8 2.2 59.2 10 u0_a1146
v2.0:
| megabytes |
NAME PID PPID CPU(s) NICE USS PSS RSS SWAP VSIZE OOM_ADJ USER
b2g 310 1 40.5 0 39.0 42.1 49.5 8.4 180.8 0 root
(Nuwa) 841 310 1.5 0 0.3 0.9 3.5 7.0 53.8 0 root
Homescreen 992 841 9.7 18 15.2 18.3 25.9 5.8 100.8 8 u0_a992
Clock 1171 841 2.7 18 8.3 12.1 20.9 2.5 64.9 10 u0_a1171
(Preallocated a 1261 841 0.7 18 5.3 7.9 14.8 2.9 59.9 1 u0_a1261
v2.1:
| megabytes |
NAME PID PPID CPU(s) NICE USS PSS RSS SWAP VSIZE OOM_ADJ USER
b2g 309 1 47.2 0 37.5 40.3 47.6 8.8 180.6 0 root
(Nuwa) 844 309 1.7 0 0.3 0.8 3.0 7.2 54.1 0 root
Homescreen 1000 844 10.6 18 13.2 16.0 23.4 7.2 97.9 8 u0_a1000
Clock 1252 844 2.8 18 8.1 11.7 20.3 2.4 64.3 10 u0_a1252
(Preallocated a 1334 844 0.8 18 5.5 8.2 15.3 2.6 60.2 1 u0_a1334
Updated•10 years ago
|
Assignee: thuang → nobody
Status: ASSIGNED → NEW
Comment 7•10 years ago
|
||
I'm not sure if the 273MB limitation is reasonable or we should try to make the new homescreen slimmer.
:kgrandon, would you mind to comment here?
Flags: needinfo?(kgrandon)
Comment 8•10 years ago
|
||
If there is no problem with your app, then I'm assuming that this is a dupe of bug 1029902.
Flags: needinfo?(kgrandon)
Updated•10 years ago
|
Priority: -- → P1
Updated•10 years ago
|
Severity: normal → blocker
Whiteboard: [273MB-Flame-Support], [2.0-exploratory] [MemShrink] → [273MB-Flame-Support], [2.0-exploratory] [MemShrink][c=memory p= s= u=2.0]
Comment 9•10 years ago
|
||
This issue reproduces less frequently on today's 2.0 with 273MB mem.
It appears to only repro 100% (3/3) when I'm listening to Radio AND looking at Clock app and a call comes will repro the bug. All the other apps mentioned in original STR don't repro the bug (combination of radio+calendar don't repro the bug either).
Tested on:
Device: Flame
Build ID: 20140717085706
Gaia: 9977a02ea62ba96425a1cc4d1bfb54a909f68905
Gecko: cc563253a046
Version: 32.0a2 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
---------------
As for the regression window, since 2.0 Aurora is marked the only affected branch, I checked the earliest 2.0 build on 6/9 with updated STR (Radio + Clock) and issue occurs there.
I then also checked latest master 2.1 with the updated STR and issue does NOT occur.
Removing regression-window-wanted tag due to issue occurs in the whole 2.0 Aurora branch and issue not occurring on latest master branch.
Comment 10•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
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Comment 11•10 years ago
|
||
We need to solve these memory pressure bugs regardless of homescreen memory usage. We've solved the homescreen problem, and this may be masked, but there's certainly a bug here still.
You will now likely need to re-regress the homescreen memory usage to see this bug.
No longer depends on: 1029902
If the symptom is fixed we can remove the blocking flag, but we need to fix the underlying issue.
Whiteboard: [273MB-Flame-Support], [2.0-exploratory] [MemShrink][c=memory p= s= u=2.0] → [273MB-Flame-Support], [2.0-exploratory] [MemShrink:P2][c=memory p= s= u=2.0]
Comment 13•10 years ago
|
||
[Blocking Requested - why for this release]:
Should we have reasonable testing environment first, especially for LMK / OOMK / ZRAM size,... in kernel configuration? Thanks.
blocking-b2g: 2.0+ → 2.0?
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage+]
Updated•10 years ago
|
QA Contact: jmercado
Comment 15•10 years ago
|
||
I was unable to reproduce this issue even using the method in comment 9 on the latest Flame 2.0 running 319 MB. The apps all remained oepened after the call.
Environmental Variables:
Device: Flame 2.0 (319 MB)
BuildID: 20140724081209
Gaia: 68226b3fd4eba752307daa5e917238bde253f5ab
Gecko: 8b920340ee28
Version: 32.0 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Comment 16•10 years ago
|
||
no repro in 319 mem, unblocking, leaving open for perf investigation
blocking-b2g: 2.0? → ---
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Comment 17•10 years ago
|
||
Since this is no longer a 2.0 blocker and doesn't repro on the 319 MB Flame, I'm closing this 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
•