Closed Bug 1003317 Opened 5 years ago Closed 2 years ago

[B2G][Tarako]Twitter closes when loading additional tweets.

Categories

(Firefox OS Graveyard :: Performance, defect, P2)

ARM
Gonk (Firefox OS)
defect

Tracking

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

RESOLVED WONTFIX
tracking-b2g -
Tracking Status
b2g-v1.3 --- unaffected
b2g-v1.3T --- affected

People

(Reporter: JMercado, Unassigned)

References

()

Details

(Keywords: memory-footprint, perf, Whiteboard: [c=memory p= s= u=tarako] [MemShrink:P2] [tarako-exploratory], LMK [partner-blocker])

Attachments

(3 files)

Description:
When scrolling through the twitter feed, the app will often close when it attempts to load more tweets.  This does not necessarily occur on every load, but will eventually occur if enough tweets are loaded.

Prerequisites: Have an active twitter account.

Repro Steps:
1) Update a Tarako to BuildID: 20140429014002
2) Open and sign into Twitter
3) Scroll through until additional tweets load
4) Repeat step 3 until the app closes.

Actual:
Twitter will close after loading more tweets.

Expected:
Twitter does not close when scrolling through tweets.

1.3T Environmental Variables:
Device: Tarako 1.3T MOZ
BuildID: 20140429014002
Gaia: b5adc5a943d3abbd6ab070a47c847f2c24891cc5
Gecko: e9890f5d4709
Version: 28.1
Firmware Version: sp6821

Notes: This bug was opened per comment 6 on bug 998455

Repro frequency: 100%
See attached: logcat, firewatch report, video
This issue does not occur on 1.3 Buri.

1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140425024003
Gaia: 32a9e3db738e0b3bc44a4d4d5c16512a2617a2cf
Gecko: c96b0cf6343f
Version: 28.0
Firmware Version: v1.2-device.cfg

Additionl tweets load without the app closing.
Nomming; users should be able to scroll feeds (I have observed a similar behavior in facebook in my 4/29 build as well).
blocking-b2g: --- → 1.3T?
Whiteboard: [tarako-exploratory] → [tarako-exploratory], LMK
Component: Gaia → Performance
Keywords: footprint, perf
Whiteboard: [tarako-exploratory], LMK → [tarako-exploratory], LMK [MemShrink]
ni? Harald, wonder if you will have further input on this? Thanks
Flags: needinfo?(hkirschner)
Harald, for this to be actionable, we'd need a profile to help us pinpoint the source of the issue.  Here's the instructions for profiling: http://mzl.la/1nJ0uYG
Whiteboard: [tarako-exploratory], LMK [MemShrink] → [tarako-exploratory], LMK [MemShrink][c=memory p= s= u=]
Priority: -- → P1
Whiteboard: [tarako-exploratory], LMK [MemShrink][c=memory p= s= u=] → [tarako-exploratory], LMK [MemShrink][c=memory p= s= u=Tarako]
I'm also experiencing the same behaviour, on the twitter app and on the twitter *website*. The browser displays the following error message (roughly translated from French): "Hmm, that's embarassing. We tried to display this webpage, but it does not respond. [Close tab] [Refresh]".

I'll try to post some profile in during the weekend.
I've followed the instructions for profiling, however, I'm unable to capture the profiles of the Twitter app, or the browser app. Indeed, as the bug seems to crash both apps, their name is no longer present in the output of ``./profile.sh ps`` after the bug, so ``./profile.sh capture`` only captures the output of the b2g process. Would that still be useful?
triage: twitter is a must have for tarako. 1.3T+
blocking-b2g: 1.3T? → 1.3T+
let's move this back to 1.3T?, partner has different feedback on Twitter
blocking-b2g: 1.3T+ → 1.3T?
qawanted/needinfo for profiling
Flags: needinfo?(nhirata.bugzilla)
Keywords: qawanted
Attached file about-memory
about-memory-0 = The first screen after sign in https://mobile.twitter.com/
about-memory-1 = After scrolling for a while

Command used:
  $ MOZ_IGNORE_NUWA_PROCESS=1 ./tools/get_about_memory.py -m

Noticeable things of Browser:
  - The size of dom and layout grows after scrolling.
  - DMD shows a large malloc from Storage.setItem(), the key and data look like:

      D/TINGt   (  585): Domstorage::SetItem() key(40)=2a15cf76123a8790799d4c6e85723690146385cb data(1313555)={"profile":{"id":"1406558947","id_str":"1406558947","name":"Ting-Yu Chou","screen_name":"janus926","location":"","settings":{"protected":false,"screen_name":"janus926","always_use_https":true,"use_cookie_personalization":false,"sleep_time":{"enabled":false,"end_time":null,"start_time":null},"geo_enabled":false,"language":"en","discoverable_by_email":true,"discoverable_by_mobile_phone":false,"display_sensitive_media":false},"description":"<div class=\"dir-ltr\" dir=\"ltr\"></div>","url":"<div class=\"dir-ltr\" dir=\"ltr\"></div>","entities":{"description":{"urls":[]}},"protected":false,"followers_count":1,"friends_count":2,"listed_count":0,"created_at":"Mon May 06 01:59:11 +0000 2013","favourites_count":0,"utc_offset":null,"time_zone":null,"geo_enabled":false,"verified":false,"statuses_count":2,"media_count":0,"lang":"en","status":{"created_at":"2014/02/27 08:48:11 +0000","id":"438958729963110401","id_str":"438958729963110401
https://drive.google.com/a/mozilla.com/file/d/0B_0LdM1CVycIM0ZYU3UxOUZSbzg/edit?usp=sharing

I captured a profile and during the capture, the twitter app died without me doing anything.  Hopefully I captured something useful.
Flags: needinfo?(nhirata.bugzilla)
Keywords: qawanted
See Also: → 976135
(In reply to Ting-Yu Chou [:ting] from comment #12)
>   - DMD shows a large malloc from Storage.setItem()

Can still reproduce after skip Storage.setItem() when the data length is longer than 10^6. Found IPC creates also a large string when it receives storage item from parent:

Unreported: 2 blocks in stack trace record 1 of 308
 2,838,528 bytes (2,833,528 requested / 5,000 slop)
 14.28% of the heap (14.28% cumulative);  46.83% of unreported (46.83% cumulative)
 Allocated at
   replace_malloc /home/ting/w/fx/os/tarako/gecko/memory/replace/dmd/DMD.cpp:1247 (0x400d474e libdmd.so+0x374e)
   malloc /home/ting/w/fx/os/tarako/gecko/memory/build/replace_malloc.c:152 (0x400931c2 libmozglue.so+0x271c2)
   nsStringBuffer::Alloc(unsigned int) /home/ting/w/fx/os/tarako/gecko/xpcom/string/src/nsSubstring.cpp:195 (0x4073ad60 libxul.so+0x33ad60)
   nsAString_internal::MutatePrep(unsigned int, char16_t**, unsigned int*) /home/ting/w/fx/os/tarako/gecko/xpcom/string/src/nsTSubstring.cpp:134 (0x4073aeb8 libxul.so+0x33aeb8)
   nsAString_internal::ReplacePrepInternal(unsigned int, unsigned int, unsigned int, unsigned int) /home/ting/w/fx/os/tarako/gecko/xpcom/string/src/nsTSubstring.cpp:169 (0x4073b28a libxul.so+0x33b28a)
   nsAString_internal::ReplacePrep(unsigned int, unsigned int, unsigned int) /home/ting/w/fx/os/tarako/objdir-gecko/dist/include/nsTSubstring.h:799 (0x4073b34c libxul.so+0x33b34c)
   nsAString_internal::Assign(char16_t const*, unsigned int, mozilla::fallible_t const&) /home/ting/w/fx/os/tarako/gecko/xpcom/string/src/nsTSubstring.cpp:321 (0x4073b71e libxul.so+0x33b71e)
   nsAString_internal::Assign(char16_t const*, unsigned int) /home/ting/w/fx/os/tarako/gecko/xpcom/string/src/nsTSubstring.cpp:300 (0x4073b736 libxul.so+0x33b736)
   IPC::ParamTraits<nsAString_internal>::Read(IPC::Message const*, void**, nsAString_internal*) /home/ting/w/fx/os/tarako/objdir-gecko/dist/include/ipc/IPCMessageUtils.h:288 (0x40892474 libxul.so+0x492474)
   mozilla::dom::PStorageChild::OnMessageReceived(IPC::Message const&) /home/ting/w/fx/os/tarako/objdir-gecko/ipc/ipdl/PStorageChild.cpp:469 (0x40915b82 libxul.so+0x515b82)
   mozilla::dom::PContentChild::OnMessageReceived(IPC::Message const&) /home/ting/w/fx/os/tarako/objdir-gecko/ipc/ipdl/PContentChild.cpp:3170 (0x408bca30 libxul.so+0x4bca30)
   mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) /home/ting/w/fx/os/tarako/gecko/ipc/glue/MessageChannel.cpp:1135 (0x4088a322 libxul.so+0x48a322)
   mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message const&) /home/ting/w/fx/os/tarako/gecko/ipc/glue/MessageChannel.cpp:1054 (0x4088bfb6 libxul.so+0x48bfb6)
   mozilla::ipc::MessageChannel::OnMaybeDequeueOne() /home/ting/w/fx/os/tarako/gecko/ipc/glue/MessageChannel.cpp:1036 (0x4088c04e libxul.so+0x48c04e)
   RunnableMethod<WebCore::ReverbConvolver, void (WebCore::ReverbConvolver::*)(), Tuple0>::Run() /home/ting/w/fx/os/tarako/gecko/ipc/chromium/src/base/task.h:308 (0x4088a056 libxul.so+0x48a056)
   mozilla::ipc::MessageChannel::DequeueTask::Run() /home/ting/w/fx/os/tarako/objdir-gecko/dist/include/mozilla/ipc/MessageChannel.h:388 (0x40889fc8 libxul.so+0x489fc8)
   MessageLoop::RunTask(Task*) /home/ting/w/fx/os/tarako/gecko/ipc/chromium/src/base/message_loop.cc:341 (0x408835b4 libxul.so+0x4835b4)
   MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) /home/ting/w/fx/os/tarako/gecko/ipc/chromium/src/base/message_loop.cc:351 (0x4088431e libxul.so+0x48431e)
   MessageLoop::DoWork() /home/ting/w/fx/os/tarako/gecko/ipc/chromium/src/base/message_loop.cc:448 (0x40884edc libxul.so+0x484edc)
   mozilla::ipc::DoWorkRunnable::Run() /home/ting/w/fx/os/tarako/gecko/ipc/glue/MessagePump.cpp:46 (0x4088d530 libxul.so+0x48d530)
   nsThread::ProcessNextEvent(bool, bool*) /home/ting/w/fx/os/tarako/gecko/xpcom/threads/nsThread.cpp:612 (0x40761b4c libxul.so+0x361b4c)
   NS_ProcessNextEvent(nsIThread*, bool) /home/ting/w/fx/os/tarako/gecko/xpcom/base/nsError.h:180 (0x407342a0 libxul.so+0x3342a0)
   mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) /home/ting/w/fx/os/tarako/gecko/ipc/glue/MessagePump.cpp:86 (0x4088d678 libxul.so+0x48d678)
   mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) /home/ting/w/fx/os/tarako/gecko/ipc/glue/MessagePump.cpp:251 (0x4088d746 libxul.so+0x48d746)
triage: let's put this to backlog and continue the investigation without blocking tarako
blocking-b2g: 1.3T? → backlog
Whiteboard: [tarako-exploratory], LMK [MemShrink][c=memory p= s= u=Tarako] → [tarako-exploratory], LMK [MemShrink][c=memory p= s= u=backlog]
Whiteboard: [tarako-exploratory], LMK [MemShrink][c=memory p= s= u=backlog] → [tarako-exploratory], LMK [MemShrink:P2][c=memory p= s= u=backlog]
Priority: P1 → P3
Whiteboard: [tarako-exploratory], LMK [MemShrink:P2][c=memory p= s= u=backlog] → [tarako-exploratory], LMK [MemShrink:P2][c=memory p= s= u=backlog] [partner-blocker]
We'll meet with Twitter today and will talk about Tarako and related bugs.
Flags: needinfo?(hkirschner)
We met with Twitter and found out that they have a low-res version of their mobile website. 

In order to test the low-res version of Twitter, you can use the user agent string below, provided by Twitter. Follow steps Harald explained in comment 80 in the bug #1007019 (https://bugzilla.mozilla.org/show_bug.cgi?id=1007019#c80) and use the string below for Twitter.
 
Harald tested this low-res Twitter app and monitored the memory usage, which is on average 11MB. It must be noted that the low-res version does not have a photo upload feature.

Mozilla/5.0 (Series40; Nokia311/03.81; Profile/MIDP-2.1 Configuration/CLDC-1.1) Gecko/20100401 S40OviBrowser/2.2.0.0.31
Priority: P3 → P2
Whiteboard: [tarako-exploratory], LMK [MemShrink:P2][c=memory p= s= u=backlog] [partner-blocker] → [c=memory p= s= u=tarako] [MemShrink:P2] [tarako-exploratory], LMK [partner-blocker]
blocking-b2g: backlog → ---
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.