466.04 KB, text/plain
456.49 KB, text/plain
27.82 KB, text/plain
1.04 KB, patch
|Details | Diff | Splinter Review|
Bug reported by Xes Garcia. E-mail is below. I cannot reproduce the bug on my ZTE Open with v1.2 on it (build: 20131204004003) Xes also sent me his user agent string: Mozilla/5.0 (Mobile; rv:26.0) Gecko: 26.0 Firefox 26.0 From: Xes Garcia <firstname.lastname@example.org> To: Elisa Helton <email@example.com> Sent: Tue, 17 Dec 2013 05:35:18 -0800 (PST) Subject: Re: Twitter App on ZTE v1.2 Hi Nice to meet you I uploaded a video and send you some screenshots with Os info and two logcats outputs, one when the app crashes and other with the browser twitter mobile web crash http://www.youtube.com/watch?v=bsAvT_CC3X8 As you can see Twitter App closes constantly without doing anything else than clicking the icon Also it shows you how crashes when I try to open twitter mobile web on the browser The video gives you more info like the Firefox Os Version and also shows like other apps like Facebook running fine. I hope it helps Xes
That looks like an OOM. QA Wanted - Can we try to reproduce this in house?
blocking-b2g: --- → koi?
Component: Preinstalled B2G Apps → General
Keywords: perf, qawanted, regression
Product: Tech Evangelism → Firefox OS
Elisa - Can you get the logcats from the reporter & attach them to the bug?
Jason, can you please direct me to a page with instructions for obtaining logcats?
Flags: needinfo?(ehelton) → needinfo?(jsmith)
Elisa - not sure on which wiki the info is hidden on, but here are the basic steps: 1.) In developer settings, enable "Remote debugging" 2.) Plug the phone in. 3.) (assuming you have android sdk installed - now, that's another story!) type $ adb logcat 4.) Reproduce the steps you made to originally show the bug. 5.) copy and paste the log output - or pipe it to a file. That's it!
(In reply to Elisa Helton from comment #3) > Jason, can you please direct me to a page with instructions for obtaining > logcats? I'm specifically looking for the logcats that Xes mentions in the above email.
Created attachment 8349253 [details] Logcat from Browser Twitter Mobile Web Crash This comes from loading twitter mobile web site on the ZTE's browser
Let's try to repro this on buri.
I've tried a couple different phones, all on the latest 1.2 Build ID: 20131217004001 First, on the Buri, I am not seeing any OOM or browser crashing however, I am seeing consistent tab crashing. If the user taps on a link that prompts another browser tab to open, that tab that was opened or the original tab will crash. I am also seeing this issue on the Leo. On both devices, I see that the app hangs frequently even with a good internet connection, if the user is tapping on a twitter user's icon (profile picture) to go to their twitter page, the feed will hang on a white screen. Again, I am not seeing the whole browser crash, or an OOM issues but I am definitely seeing other issues that will result in a bad user experience. Gaia 4f53ba8b3628ac311253fc28dfdf66e7ba6832de SourceStamp 129ad3c335a5 BuildID 20131217004001 Version 26.0
(In reply to Sarah Parsons from comment #9) > I've tried a couple different phones, all on the latest 1.2 Build ID: > 20131217004001 > > First, on the Buri, I am not seeing any OOM or browser crashing however, I > am seeing consistent tab crashing. If the user taps on a link that prompts > another browser tab to open, that tab that was opened or the original tab > will crash. I am also seeing this issue on the Leo. > > On both devices, I see that the app hangs frequently even with a good > internet connection, if the user is tapping on a twitter user's icon > (profile picture) to go to their twitter page, the feed will hang on a white > screen. > > Again, I am not seeing the whole browser crash, or an OOM issues but I am > definitely seeing other issues that will result in a bad user experience. > > Gaia 4f53ba8b3628ac311253fc28dfdf66e7ba6832de > SourceStamp 129ad3c335a5 > BuildID 20131217004001 > Version 26.0 Note - a tab crash can imply either a functional crash or an OOM if you see the sad face error page. Can we get a dmesg log when the tab crash occurs?
This might be an OOM here: <4>[ 649.709448] send sigkill to 492 (Browser), adj 2, size 25261 re-adding perf - we discussed previously that perf was encompassing memory issues.
perf keyword was deliberately removed from fxos-perf triage. Thanks.
(In reply to Hubert Figuiere [:hub] from comment #13) > perf keyword was deliberately removed from fxos-perf triage. Thanks. You need a provide a rationale why. Please don't flip flags without context. This is an OOM, which keeps the keyword.
during triage we decided that since it was already owned, and since it is a third party, that it is not for us. now when somebody from fxos-perf@ remove the keyword during triage, do you think it really needs explaining? it is not like we are vandalizing or something.
(In reply to Hubert Figuiere [:hub] from comment #15) > during triage we decided that since it was already owned, and since it is a > third party, that it is not for us. It is isn't already owned & it isn't a third party issue. I was marked as an assignee originally because it's believed that this is a platform regression, not a bug in twitter, given that we've never seen this problem in any partner app testing in past releases before 1.2. It specifically looks memory related because of these things: 1. The YouTube video shows evidence of an abnormal process kill in the app & a tab content process - which implies there's a good chance this is an OOM, not a crash. 2. There's a sigkill present in the dmesg log, which is indicator of an OOM. 3. We know there's been a wide variety of memory problems in 1.2 involving Skia GL. This could potentially be yet another example of a fallout from introducing Skia GL into the build. > > now when somebody from fxos-perf@ remove the keyword during triage, do you > think it really needs explaining? it is not like we are vandalizing or > something. Yes actually I think it does, especially when it's dealing with a content escalation involving a top partner app at the near end of a release. The challenge with diagnosing issues like these is we often have vague information to go off of. However, we need to be supportive to help figure out the right people to talk to. I sent this over to the perf team because of the three pieces of evidence above suggested this was an OOM, which to my understanding, was actively tracked by the perf team. We can get more information here to see if this is a Skia GL related or not. Flagging qawanted to see if this reproduces with Skia GL disabled (see https://bugzilla.mozilla.org/show_bug.cgi?id=947523#c21 for how to do this). hub - does that help clarify things a bit better? Are there any outstanding questions that need to be answered to prove or disprove this is a perf issue?
I can still reproduce this issue on the Buri 1.2 Build ID:20131218004002 after disabling Skia GL. Gaia 38338b31b554cdb8c6242b15a966f171a0e7abaa SourceStamp dcffefec8206 BuildID 20131218004002 Version 26.0
Can we confirm this isn't reproducing on 1.1? I don't think it should be, but it's good to double check this.
Sarah: Can you please test this on 1.1 as well? That will help the triage team address this issue during tomorrow's triage.
What OEM firmware are you running this on? I was only able to reproduce once. I noticed some Adreno messages in logcat I don't see from my device, though, so I'm wondering what gonk this is.
Tested on ZTE Open v1.1 and I could not reproduce any crashing of the Twitter app Tested on ZTE Open v1.2 and I could not reproduce any crashing of the Twitter app. Build: 20131204004003 Platform Version 26.0
(In reply to Ben Kelly [:bkelly] from comment #20) > What OEM firmware are you running this on? I was only able to reproduce > once. I noticed some Adreno messages in logcat I don't see from my device, > though, so I'm wondering what gonk this is. FWIW - Sarah's reproduction was done on a Buri device running a 1.2 base image with the latest gaia/gecko on top.
I think this is just memory spiking when we decode all the images on first load. Running b2g-info in a loop I see the memory for twitter rise above 80+MB and then drop back down. This typically kills the homescreen and is sometimes enough to kill twitter as well. Enabling the "layout.imagevisibility.enabled" pref from bug 847223 helps out a lot here. It prevents us from decoding all the avatar images that are offscreen. With this enabled memory for twitter seems to peak at ~50MB. This allows even the homescreen to survive. I spoke with Timothy on IRC and he indicated "layout.imagevisibility.enabled" was simply disabled until further testing could be done. No bugs or fixes were found, however, so it should be safe to enable in b2g26. I'll make a patch to flip the pref.
Assignee: nobody → bkelly
Status: NEW → ASSIGNED
Whiteboard: [MemShrink][perf-reviewed] → [MemShrink][perf-reviewed][c= p=3 s= u=]
Created attachment 8350760 [details] [diff] [review] b2g26 patch: Enable pref to avoid decoding hidden images on load. Here is a patch to enable bug 847223 on b2g26. Note, we need a koi+ here before this can land.
Attachment #8350760 - Flags: review?(fabrice)
Note that this is already enabled in 1.3 and forward.
status-b2g-v1.2: --- → affected
status-b2g-v1.3: --- → fixed
Whiteboard: [MemShrink][perf-reviewed][c= p=3 s= u=] → [MemShrink][c= p=3 s= u=]
Looks like we've got a path forward here, so clearing qawanted & needinfo. Thanks Ben for the help.
Attachment #8350760 - Flags: review?(fabrice) → review+
Checkin-needed to b2g26 branch.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
status-b2g-v1.2: affected → fixed
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.