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.
Please see this video http://youtu.be/mfbOQSBmCgg
How many times do you need to repeat steps 3 - 5 typically to reproduce this?
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
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?
The email app closes before the contact app is ever opened.
(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?
The contact does not get saved because the user is only able to save a contact when they are in the contacts app
How often can this reproduce on the first try?
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?
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
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?
Before noming this, another question - does this reproduce with emails with a small amount of content?
blocking-b2g: 1.3T? → ---
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
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.
Hi jcastro, The OOM has been fixed (bug 998395) and landed on v1.3t. Could you help to verify this case?
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
Whiteboard: [tarako-exploratory][MemShrink] → [tarako-exploratory][MemShrink][c=memory p= s= u=]
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.