[B2G][Tarako][Email]Electing to Save a contact results in a close of the Email app.

RESOLVED WONTFIX

Status

defect
P2
normal
RESOLVED WONTFIX
5 years ago
2 years ago

People

(Reporter: JMercado, Unassigned)

Tracking

({memory-footprint, perf})

unspecified
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(b2g-v1.3 unaffected, b2g-v1.3T affected)

Details

(Whiteboard: [c=memory p= s= u=tarako] [MemShrink:P2] [tarako-exploratory])

Attachments

(2 attachments)

Description:
Often when a user selects to save a new contact from an email, the email app will close.  This occurs more often if the user has loaded additional emails recently before attempting to save the contact.

Prerequisites:
Have an email account with many emails sync'd to the device

Repro Steps:
1) Update a Tarako to BuildID: 20140430014008
2) Open the Email app.
3) Scroll down through the email list until more are being loaded in.
4) Open any email and select any of the email addresses in the to or from fields.
5) Select Save new contact.
6) If the app did not close, return to the email list and repeat steps 3-5.

Actual:
The email app closes without sending the user to the contacts app.

Expected:
The email app does not close and the user can return to it after successfully saving a new contact.

1.3T Environmental Variables:
Device: Tarako 1.3T MOZ
BuildID: 20140430014008
Gaia: f9b62bd1135f4edf8317fff1c2947b9d99438d79
Gecko: ba50f734b815
Version: 28.1
Firmware Version: sp6821a-Gonk-4.0-4-29

Repro frequency: 20% 10/50 attempts
See attached: logcat, firewatch report, video
This issue did not reproduce on Buri 1.3

1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140428024001
Gaia: 32a9e3db738e0b3bc44a4d4d5c16512a2617a2cf
Gecko: d7b1e90008e5
Version: 28.0
Firmware Version: v.12-device.sfg

User was able to get to and return from adding a contact on 20/20 tries.
How many times do you need to repeat steps 3 - 5 typically to reproduce this?
Keywords: qawanted
On average I was able to reproduce this issue after 5 attempts. But it is possible to have it occur on the first try.

1.3t Environmental Variables:
Device: Tarako 1.3t
BuildID: 20140501014002
Gaia: d26a776beae0070b0032248a2ce482bbe6321a6d
Gecko: e90f4b655511
Version: 28.1
Firmware Version: sp6821
Keywords: qawanted
It's being low memory killed : 
04-30 17:13:42.554   511   511 I log     : <4>0[ 94.548108] lowmem_shrink select 412 (E-Mail), adj 2, size 15527, to kill
Does the contact actually get saved or not when this bug reproduces?
Keywords: qawanted
The email app closes before the contact app is ever opened.
Keywords: qawanted
(In reply to Jayme Mercado from comment #8)
> The email app closes before the contact app is ever opened.

That doesn't directly answer my question here - that does mean that the contact never gets saved?
Keywords: qawanted
The contact does not get saved because the user is only able to save a contact when they are in the contacts app
Keywords: qawanted
How often can this reproduce on the first try?
Keywords: qawanted
Only 2 of the original 10 repros in comment 0 were done on the first try.  I have done another 10 repros today and only 1 was on the first try.  Total 3/20 were on first try.
Does this reproduce if you try to save a contact via the messages app on tarako?
Keywords: qawanted
I think he ran into a similar case of bug 998395 and found a way to LMK while trying to save a contact.  I'm not sure if it will reproduce with SMS without having a large SMS.  Is modifying the SMS via make reference-workload-x-heavy valid for v1.3t?
I was unable to reproduce this bug when adding a new contacts via MMS/SMS app. 

1.3t Environmental Variables:
Device: Tarako 1.3t MOZ
BuildID: 20140501014002
Gaia: d26a776beae0070b0032248a2ce482bbe6321a6d
Gecko: e90f4b655511
Version: 28.1
Firmware Version: sp6821a-Gonk-4.0-4-29
Keywords: qawanted
A 20% failure rate on a common use case of an email app involving an OOM seems bad. We should either turn the feature off or fix this.
blocking-b2g: --- → 1.3T?
Keywords: footprint, perf
Whiteboard: [tarako-exploratory] → [tarako-exploratory][MemShrink]
Before noming this, another question - does this reproduce with emails with a small amount of content?
blocking-b2g: 1.3T? → ---
Keywords: qawanted
Supplement to comment #15
I attempted to use the X-heavy script and it locked up the Tarako.
I was able to use the reference-workload-light and medium script. This resulted in expected/working behaviour in regards to making new contacts via SMS.

In response to comment #17
I was UNABLE to reproduce this bug with about 15 emails.

1.3t Environmental Variables:
Device: Tarako 1.3t MOZ
BuildID: 20140501014002
Gaia: d26a776beae0070b0032248a2ce482bbe6321a6d
Gecko: e90f4b655511
Version: 28.1
Firmware Version: sp6821a-Gonk-4.0-4-29
Keywords: qawanted
As Naoki alludes to in comment 14, the STRs from comment 0 suggest there is some overlap with bug 998395 here.  Namely, that bug can cause our memory usage to be higher from scrolling through the list and causing snippets to be fetched (or if message bodies are displayed.)

I have a patch up on bug 998395 but I need 1.3T+ to be able to land it.
Depends on: 998395
Marking qawanted to retest post landing of bug 998395.
Keywords: qawanted
Hi jcastro,

The OOM has been fixed (bug 998395) and landed on v1.3t. Could you help to verify this case?
Flags: needinfo?(jcastro)
Bug is Reproducible on the 5/7/14 V1.3t Build

Bug reproduce 3/30 attempts. Most instances of the bug happened after the initial set up of the email account. The other happened when the user hit Load more and then tried to save out a contact.

Updated Repro Steps:
1) Update a Tarako to BuildID: 20140430014008
2) Open the Email app.

** Additional step: Set up a new email account account (has emails/its not associated with phone)  **

3) Scroll down through the email list until more are being loaded in.

** Additional step: Hit the load more button at the bottom of the list

4) Open any email and select any of the email addresses in the to or from fields.
5) Select Save new contact.
6) If the app did not close, return to the email list and repeat steps 3-5

1.3t Environmental Variables:
Device: Tarako 1.3t MOZ
BuildID: 20140507014006
Gaia: 25a17d9d7143977ea9a81ed310098e326609d248
Gecko: 68a2f24960d2
Version: 28.1
Firmware Version: sp6821a-Gonk-4.0-4-29
Flags: needinfo?(jcastro)
Whiteboard: [tarako-exploratory][MemShrink] → [tarako-exploratory][MemShrink][c=memory p= s= u=]
Priority: -- → P2
So, in the case we've just created a new account, we do expect that we'll have loaded some extra JS to handle the ActiveSync autodiscover stuff.  (apps/email/js/ext/mailapi/protocollayer.js which is 108K pre-minification).

That's not a huge amount of code so I think the correlation that all messages are newly synced and newly snippeted/etc. is increasing the amount of garbage/memory-turnover that we're generating vastly.  This seems consistent with the STR requiring repeating loading more new messages.


So I think from an email app perspective this is something that isn't something we can address within the email app on the v1.3t branch.  I do think the platform might be able to GC more aggressively to keep email's footprint down.  But most email optimizations at this stage would involve us optimizing code we are planning to abandon as part of bug 885110, ideally in the 2.0 time-frame.

Having said that, if the performance or other engineering teams wants to investigate any low-hanging fruit within the email app itself, I won't stop them and am happy to cheer for them :)
Whiteboard: [tarako-exploratory][MemShrink][c=memory p= s= u=] → [tarako-exploratory][MemShrink:P2][c=memory p= s= u=]
Whiteboard: [tarako-exploratory][MemShrink:P2][c=memory p= s= u=] → [c=memory p= s= u=tarako] [MemShrink:P2] [tarako-exploratory]
Closing out old Firefox OS specific memshrink bugs.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.