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)

ARM
Gonk (Firefox OS)
defect

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)

Attached file Logcat_Call_App_Crash .txt (deleted) —
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
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)
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)
Component: Gaia::Dialer → Performance
Keywords: footprint, perf
Whiteboard: [273MB-Flame-Support], [2.0-exploratory] → [273MB-Flame-Support], [2.0-exploratory] [MemShrink]
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.
Thinker, do you have any suggestion on this bug? Thanks.
Flags: needinfo?(tlee)
Hi, Ting-Yuan, can you help to take a look on this bug? Thanks.
Flags: needinfo?(thuang)
Flags: needinfo?(tlee)
Assignee: nobody → thuang
Status: NEW → ASSIGNED
Flags: needinfo?(thuang)
Attached file about-memory.tgz (deleted) —
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
Assignee: thuang → nobody
Status: ASSIGNED → NEW
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)
If there is no problem with your app, then I'm assuming that this is a dupe of bug 1029902.
Flags: needinfo?(kgrandon)
Priority: -- → P1
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]
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.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
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
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
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]
[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?
QA Wanted to retest under the 319 MB Flame on 2.0.
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage+]
QA Contact: jmercado
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
no repro in 319 mem, unblocking, leaving open for perf investigation
blocking-b2g: 2.0? → ---
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
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
Target Milestone: --- → 2.1 S1 (1aug)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: