Closed
Bug 1023796
Opened 10 years ago
Closed 10 years ago
Vertical homescreen without icons in applications after an app gets OOMed
Categories
(Core Graveyard :: DOM: Apps, defect)
Tracking
(blocking-b2g:2.0+, firefox31 wontfix, firefox32 fixed, firefox33 fixed, b2g-v2.0 fixed, b2g-v2.1 fixed)
People
(Reporter: lolimartinezcr, Assigned: aus)
References
Details
(Whiteboard: [caf priority: p1][systemsfe][CR 686636][p=5])
Attachments
(6 files)
Tested Hamachi 2.1 Gecko: 1ce168a Gaia: 207cacb Reproducible: 25% Actual result: Sometimes vertical homescreen without icons. Attached image NOTE: without steps to reproduce.This error happens randomly
Updated•10 years ago
|
Blocks: vertical-homescreen
Comment 1•10 years ago
|
||
I don't have this device but logs will be very appreciate here in order to detect some Javascript error or something like that. Many thanks
Updated•10 years ago
|
Whiteboard: [systemsfe]
Comment 2•10 years ago
|
||
Let's try to get logs here as Cristian suggests & confirm the 25% reproducibility.
Keywords: qawanted
Comment 3•10 years ago
|
||
We've also landed a *lot* of icon patches since that gaia commit, basically a full rewrite of the icon system. Please try latest tip and let us know if you still see it. Logcat would also be good as well. Going to close as worksforme for now as I can't reproduce and neither can any of our coworkers. If you do still see this, please reopen with updated version numbers. (We also aren't really testing on hamachi, so if the QA team can help us do that, and it's a valid use case - it would be appreciated).
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(lolimartinezcr)
Resolution: --- → WORKSFORME
Comment 5•10 years ago
|
||
Reopening to investigate it. I am fairly certain that it's just a problem with the Buri, perhaps too much memory usage, but we should figure out exactly what's causing it.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Updated•10 years ago
|
blocking-b2g: --- → 2.0?
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+]
Keywords: qawanted
Summary: Vertical homescreen without icons in applications → Vertical homescreen without icons in applications after an app gets OOMed
Comment 7•10 years ago
|
||
After analyzing the dupes, the root cause of the problem is the fact that the homescreen can't manage to recover if an app gets OOM killed by the LMK.
Flags: needinfo?(lolimartinezcr)
Updated•10 years ago
|
blocking-b2g: 2.0? → 2.0+
Updated•10 years ago
|
Whiteboard: [systemsfe] → [systemsfe][MemShrink]
Comment 9•10 years ago
|
||
A possible cause of this could be that the system app sent a wrong iframe.setVisible(true) call / or does not sent it. If would be good to know if when it reproduce you can pan vertically or not ? If not, that's a system app issue. One other possible issue, which is in the homescreen this time, could be a blob issue. Blob get removed by our image discarding code in the platform and are never reloaded because the homescreen has revoke the blob url.
Comment 10•10 years ago
|
||
I just tested this a bunch on the latest gecko/gaia for a hamchi and I'm not able to reproduce this as stated. I do occasionally see the text, but the icons always come in (although it may take a second or two). There's certainly some performance work that we can do here, but I am looking for a STR for the no-icon case still. When you guys look at qawanted please let me know if you can still reproduce this issue, a video might be useful as well.
Comment 11•10 years ago
|
||
(In reply to Kevin Grandon :kgrandon from comment #10) > I just tested this a bunch on the latest gecko/gaia for a hamchi and I'm not > able to reproduce this as stated. I do occasionally see the text, but the > icons always come in (although it may take a second or two). There's > certainly some performance work that we can do here, but I am looking for a > STR for the no-icon case still. When you guys look at qawanted please let me > know if you can still reproduce this issue, a video might be useful as well. Video link: https://www.dropbox.com/s/deb9zlo08nb0mg7/VID_20140613_154236.mp4 Basically you can skip to the last 20 seconds. I was trying for a minute and a half for the e-mail app to eventually crash by doing lots of zoom in/outs and scrolls.
Comment 12•10 years ago
|
||
FWIW, I'm no longer able to reproduce the bug 1024683 behavior (dup of this one) on my hamachi. When I created the bug, it was 100% reproducible. Now, 0%. Lesson learned: get the logcat when you create the bug. Also FWIW, the behaviour I observed was that after killing an app in the foreground, the text of the icons on the homescreen were there but no icons. In the video, there are no icons nor text. In any event, as I mentioned, I'm unable to recreate.
Comment 13•10 years ago
|
||
(In reply to No-Jun Park [:njpark] from comment #11) > Video link: > https://www.dropbox.com/s/deb9zlo08nb0mg7/VID_20140613_154236.mp4 Thanks, and that definitely looks like an interesting email problem, but I don't think it's related to vertical homescreen. (In reply to Russ Nicoletti [:russn] from comment #12) > FWIW, I'm no longer able to reproduce the bug 1024683 behavior (dup of this > one) on my hamachi. When I created the bug, it was 100% reproducible. Now, > 0%. Lesson learned: get the logcat when you create the bug. Ok, thank you very much Russ. Like I said we had several platform/gaia patches in the last 2 days, so I would not be surprised if that fixed it. I would also not be surprised if there is still an issue here. I'm going to keep looking at this over the weekend, but will close for now unless someone has a solid STR and logcat.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → WORKSFORME
Comment 14•10 years ago
|
||
Oh there's a separate bug for the e-mail issue.(Bug 1019693) the things is that at the end of the video, (after it crashes with OOM) the homescreen does not show the icons. I have to restart the phone for that. Sorry for being not clear.
Comment 15•10 years ago
|
||
And since Bug 1019693 is consistently reproducible, the vertical homescreen with no icon issue is consistently reproducible as well.
Comment 16•10 years ago
|
||
(In reply to No-Jun Park [:njpark] from comment #14) > Oh there's a separate bug for the e-mail issue.(Bug 1019693) the things is > that at the end of the video, (after it crashes with OOM) the homescreen > does not show the icons. I have to restart the phone for that. Sorry for > being not clear. Ooh, that makes more sense, I skipped the last few seconds of that video :) Reopening to investigate this then.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Updated•10 years ago
|
Comment 17•10 years ago
|
||
Aus - any chance you have a hamachi and want to investigate this tricky one?
Flags: needinfo?(aus)
Comment 18•10 years ago
|
||
I have uploaded a logcat. I was able to repro this bug following these STR: 1) Update a Flame to 20140618040513 2) Connect to Wifi or Data 3) Open marketplace 4) Install the app 'Terra' 5) Open the app 6) Quickly scroll through the app and press the home button 7) Repeat steps 5-6 until bug occurs Following these STR the repro rate is around 70%
Updated•10 years ago
|
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+] → [VH-FL-blocking-][VH-FC-blocking+][QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Comment 19•10 years ago
|
||
Issue occurred on 2.1 Flame Environmental Variables: Device: Flame Build ID: 20140618040513 Gaia: 431aed0a7c7560c6eacd35ea69aa0a7a4ebe72c7 Gecko: 37f08ddaea48 Version: 33.0a1 Firmware Version: v121-2
Updated•10 years ago
|
Flags: needinfo?(jmitchell)
Assignee | ||
Comment 20•10 years ago
|
||
Yep, I'll find a Hamachi here in Taipei and have a look...
Flags: needinfo?(aus)
Assignee | ||
Comment 21•10 years ago
|
||
I'm having a little trouble reproducing this with the STRs in Comment #18 on my Flame device with v2.1 and Firmware v121-2. However, here's my working theory here. When the application gets killed and we're transitioning to the homescreen, it's likely the process that's getting killed is still shutting down. This means the memory that it was using hasn't been fully reclaimed. Under these operating conditions it means the homescreen will be unable to allocate the necessary memory to load the icons. In theory going back into an other application and back to the homescreen should make the icons become visible again. Is this the case?
Assignee | ||
Comment 22•10 years ago
|
||
I'm having a little trouble reproducing this with the STRs in Comment #18 on my Flame device with v2.1 and Firmware v121-2. However, here's my working theory here. When the application gets killed and we're transitioning to the homescreen, it's likely the process that's getting killed is still shutting down. This means the memory that it was using hasn't been fully reclaimed. Under these operating conditions it means the homescreen will be unable to allocate the necessary memory to load the icons. In theory going back into an other application and back to the homescreen should make the icons become visible again. Is this the case?
Flags: needinfo?(jschmitt)
Comment 23•10 years ago
|
||
I don't think jschmitt will be able to help answer this. If you are having trouble reproducing this, try using https://bugzilla.mozilla.org/show_bug.cgi?id=1024536's STR. You basically need an app that will OOM to cause this bug.
Flags: needinfo?(jschmitt)
Comment 24•10 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #23) > I don't think jschmitt will be able to help answer this. If you are having > trouble reproducing this, try using > https://bugzilla.mozilla.org/show_bug.cgi?id=1024536's STR. You basically > need an app that will OOM to cause this bug. https://bugzilla.mozilla.org/show_bug.cgi?id=1006088 is an easy one to use btw to test this if you use that app as an e.me app.
Assignee | ||
Comment 25•10 years ago
|
||
:jsmith, I was hoping he could tell me if the steps suggested worked to bring the homescreen back to a usable state with icons without having to restart the phone.
Comment 26•10 years ago
|
||
(In reply to Ghislain Aus Lacroix [:aus] from comment #25) > :jsmith, > > I was hoping he could tell me if the steps suggested worked to bring the > homescreen back to a usable state with icons without having to restart the > phone. Oh now I understand now. Okay, let me flag qawanted then for this.
Keywords: qawanted
Comment 27•10 years ago
|
||
I see this issue sometimes when closing an app from the "open apps" flow (hold down home button). It seems more likely to reproduce when closing an app while it is "active" (visible). In any event, regarding comment #22, after it happens, I'm not able to invoke any app. I've attached logcat output.
Comment 28•10 years ago
|
||
After this has happened, tapping anywhere on the homescreen produces: I/Gecko ( 921): ###!!! [Parent][MessageChannel] Error: Channel error: cannot send/recv
Comment 29•10 years ago
|
||
More investigation into comment #22 scenario: when opening an app via app manager, and then on device (buri) going to homescreen, icons are still not visible. Logcat for this scenario: I/Gecko ( 1724): ###################################### forms.js loaded I/Gecko ( 1724): ############################### browserElementPanning.js loaded I/Gecko ( 1724): ######################## BrowserElementChildPreload.js loaded E/Sensors ( 921): sensors_poll_context_t::activate index is 0, handle is enabled is 0,the enable is 1 E/Sensors ( 921): happy,bmasensor is enable,the mEnabled is 0,the handle is 0,the enabled is 1 E/Sensors ( 921): BmaSensor: handle (0) ,BMA222_IOCTL_SET_FLAG E/Sensors ( 921): BmaSensor: Control set 1 E/memalloc( 921): /dev/pmem: No more pmem available W/memalloc( 921): Falling back to ashmem I/Gonk ( 921): Setting nice for pid 1747 to 18 I/Gonk ( 921): Changed nice for pid 1747 from 0 to 18. I/Gecko ( 1747): ###################################### forms.js loaded I/Gecko ( 1747): ############################### browserElementPanning.js loaded I/Gecko ( 1747): ######################## BrowserElementChildPreload.js loaded I/Gecko ( 921): I/Gecko ( 921): ###!!! [Parent][MessageChannel] Error: Channel error: cannot send/recv I/Gecko ( 921): I/Gonk ( 921): Setting nice for pid 1031 to 1 I/Gonk ( 921): Changed nice for pid 1031 from 18 to 1. E/Sensors ( 921): sensors_poll_context_t::activate index is 0, handle is enabled is 0,the enable is 0 E/Sensors ( 921): happy,bmasensor is enable,the mEnabled is 1,the handle is 0,the enabled is 0 E/Sensors ( 921): BmaSensor:ddds BMA222_IOCTL_SET_FLAG E/Sensors ( 921): BmaSensor: Control set 0 I/Gecko ( 921): I/Gecko ( 921): ###!!! [Parent][MessageChannel] Error: Channel error: cannot send/recv I/Gecko ( 921): E/memalloc( 921): /dev/pmem: No more pmem available W/memalloc( 921): Falling back to ashmem E/memalloc( 921): /dev/pmem: No more pmem available W/memalloc( 921): Falling back to ashmem
Updated•10 years ago
|
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+][QAnalyst-Triage?] → [VH-FL-blocking-][VH-FC-blocking+]
Comment 30•10 years ago
|
||
Note for qawanted - we also need an updated logcat w/console enabled. The logcat included here doesn't have that.
![]() |
||
Updated•10 years ago
|
Whiteboard: [systemsfe][MemShrink] → [systemsfe]
Comment 31•10 years ago
|
||
I tried to reproduce this bug using the email app or Cupcakes VS Veggies, on a hamachi, and I failed to reproduce the exact symptom. Can you guys confirms that it still happens ? On the other side what I can see sometimes is an error, where the homescreen is completely broken (no icons at all). It does not reproduce 100% of the time, and it seems like a fun race condition in WebApps.jsm and the memory-pressure event, which results into broken manifest that does not contains any data - and so the homescreen can't load anything. So I wonder if that can also be the cause of this bug in some situations. Hard to tell.
Assignee | ||
Comment 32•10 years ago
|
||
Vivien, that's what I managed to observe once while trying to reproduce it. But, my repro rate is *very* low. I only managed to make it happen once.
Comment 33•10 years ago
|
||
Fabrice, I can't tell if this is the exact same bug as the one describe in this bug, as when I tried to reproduce it, this one is the issue I found. This patch makes a |let| copy of the variable in order to prevent a weird race where this._manifestCache is cleared while reading the manifests. This can arrive if the device is under a memory-pressure when the homescreen is rebooting and ask for mozApps.mgmt.getAll(). The results is that the apps cache in the child is set up with completely broken manifests.
Attachment #8446010 -
Flags: review?(fabrice)
Comment 34•10 years ago
|
||
(In reply to Ghislain Aus Lacroix [:aus] from comment #32) > Vivien, that's what I managed to observe once while trying to reproduce it. > But, my repro rate is *very* low. I only managed to make it happen once. I have a almost 100% repro rate with the followin steps: - Launch b2g - Launch about:app-manager in Firefox and click the 'Debug Main Process' button with the device attached - In the console of the main process type: Services.obs.notifyObservers(null, "memory-pressure", ""); to simulate a memory pressure - Kill the homescreen on the device with a shell command of your choice - Very quickly go back to the console of the main process and continusously type the mentioned command. - ouf!
Assignee | ||
Comment 35•10 years ago
|
||
Yep... Those STRs work for me! I don't mind following up on this one and landing the fix, you seem to have a lot assigned to you right now. :) The patch fixes the issue for me on Flame with v121-2, gaia master, moz-central.
Assignee: nobody → aus
Status: REOPENED → ASSIGNED
Target Milestone: --- → 2.0 S5 (4july)
Comment 36•10 years ago
|
||
Thanks for taking this over Aus, moving into the proper component as it's a dom patch, although the problem manifests in the vertical homescreen.
Component: Gaia::Homescreen → DOM: Apps
Product: Firefox OS → Core
Comment 37•10 years ago
|
||
Comment on attachment 8446010 [details] [diff] [review] memory-pressure-read-manifest-race.patch Review of attachment 8446010 [details] [diff] [review]: ----------------------------------------------------------------- Makes sense, damn async tasks... Ideally we should make the cache a class that we can lock/unlock though. Can you file a follow up?
Attachment #8446010 -
Flags: review?(fabrice) → review+
Comment 38•10 years ago
|
||
Comment 39•10 years ago
|
||
Attached logcat "oom_flame_v2.0" in attachment field. I was able to reproduce the bug on a Flame device with a 2.0 build. I used the following STR: 1. Launch Browser app. 2. Long press home button and close Browser app. 3. Repeat steps 1 and 2 about 5 to 12 times. Environmental Variables: Device: Flame 2.0 Build ID: 20140625124605 Gaia: c478c43229883cee2afd09c6edb42d29a46cc500 Gecko: 8940337ccb5c Version: 32.0a2 (2.0) Firmware Version: v122
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+] → [VH-FL-blocking-][VH-FC-blocking+] [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Updated•10 years ago
|
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+] [QAnalyst-Triage?] → [VH-FL-blocking-][VH-FC-blocking+] [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Assignee | ||
Comment 40•10 years ago
|
||
Fabrice, I'll file a follow up to make this a locked operation. And, I'll go ahead and land this patch on master + 2.0.
Assignee | ||
Comment 41•10 years ago
|
||
Comment on attachment 8446010 [details] [diff] [review] memory-pressure-read-manifest-race.patch [Approval Request Comment] Bug caused by (feature/regressing bug #): See bug description. User impact if declined: Icons don't load on homescreen until user restarts phone. Testing completed (on m-c, etc.): Flame Risk to taking this patch (and alternatives if risky): Low risk String or IDL/UUID changes made by this patch: None
Attachment #8446010 -
Flags: approval-mozilla-aurora?
Assignee | ||
Updated•10 years ago
|
status-b2g-v2.0:
--- → affected
status-b2g-v2.1:
--- → affected
status-firefox32:
--- → affected
status-firefox33:
--- → affected
Assignee | ||
Updated•10 years ago
|
Keywords: leave-open
Updated•10 years ago
|
Whiteboard: [systemsfe] → [systemsfe][CR 686636]
Updated•10 years ago
|
Blocks: CAF-v2.0-FC-metabug
Updated•10 years ago
|
Whiteboard: [systemsfe][CR 686636] → [caf priority: p1][systemsfe][CR 686636]
Comment 44•10 years ago
|
||
In comment 35 aus states that this patch fixes the issue for him. Now that the bug is on m-c, do any of the people who were able to reproduce (Vivien, ddixon, loli, Josh) have access to a m-c build on which they can confirm that they can no longer reproduce with the fix?
Flags: needinfo?(lolimartinezcr)
Flags: needinfo?(jschmitt)
Flags: needinfo?(ddixon)
Flags: needinfo?(21)
Comment on attachment 8446010 [details] [diff] [review] memory-pressure-read-manifest-race.patch Review of attachment 8446010 [details] [diff] [review]: ----------------------------------------------------------------- (In reply to Lawrence Mandel [:lmandel] from comment #44) > In comment 35 aus states that this patch fixes the issue for him. Now that > the bug is on m-c, do any of the people who were able to reproduce (Vivien, > ddixon, loli, Josh) have access to a m-c build on which they can confirm > that they can no longer reproduce with the fix? I cherry-picked patch from #comment 41 on top of following gaia/gecko running on MSM8610 (256MB configuration) : gaia : https://www.codeaurora.org/cgit/quic/lf/b2g/mozilla/gaia/commit/?h=mozilla/v2.0&id=9d2f7bd16a8dc0c74c97c5a40d2f0731f3dfff4b gecko : https://www.codeaurora.org/cgit/quic/lf/b2g/mozilla/gecko/commit/?h=mozilla/v2.0&id=32c226e5a7adbb95e9c4ee003dc9e64699da03e1 But i can still reproduce this issue
Updated•10 years ago
|
Attachment #8446010 -
Flags: feedback-
error logs for #comment 45
I found that homescreen main thread is waiting in IPDL::PContent::RecvFlushMemory gfxContext::Paint() [1] nsCycleCollector::Collect() [2] Homescreen spawned another IPC thread which is stuck in MessagePump::Wait()[3] Easy STR to reproduce this issue: 1) Flash build on device which is memory restricted to use only 256MB. 2) Copy lots of contents to sdcard and launch gallery. 3) You will see gallery is scanning images and now try to zoom in/out an image. This will force to use more memory and device will become slower 4) Minimize gallery and launch camcorder and try to record video 5) Stop recording video and Minimize camcorder. 6) Homescreen will not show any icons You need to follow step #3 properly to make sure that you are using lots of memory. [1] http://dxr.allizom.org/mozilla-central/source/gfx/thebes/gfxContext.cpp#1532 [2] http://dxr.mozilla.org/mozilla-central/source/xpcom/base/nsCycleCollector.cpp#4127 [3] http://dxr.mozilla.org/mozilla-central/source/ipc/chromium/src/base/message_pump_default.cc#56
Updated•10 years ago
|
Flags: needinfo?(msreckovic)
Reporter | ||
Comment 48•10 years ago
|
||
(In reply to Lawrence Mandel [:lmandel] from comment #44) > In comment 35 aus states that this patch fixes the issue for him. Now that > the bug is on m-c, do any of the people who were able to reproduce (Vivien, > ddixon, loli, Josh) have access to a m-c build on which they can confirm > that they can no longer reproduce with the fix? With Hamachi, for me this bug isn't reproducible 2.0 Gecko:bffdf5e Gaia:2248c03
Flags: needinfo?(lolimartinezcr)
Comment 49•10 years ago
|
||
(In reply to Tapas Kumar Kundu from comment #47) > I found that homescreen main thread is waiting in > > IPDL::PContent::RecvFlushMemory > gfxContext::Paint() [1] > nsCycleCollector::Collect() [2] > > Homescreen spawned another IPC thread which is stuck in > MessagePump::Wait()[3] > > Easy STR to reproduce this issue: > 1) Flash build on device which is memory restricted to use only 256MB. > 2) Copy lots of contents to sdcard and launch gallery. > 3) You will see gallery is scanning images and now try to zoom in/out an > image. This will force to use more memory and device will become slower > 4) Minimize gallery and launch camcorder and try to record video > 5) Stop recording video and Minimize camcorder. > 6) Homescreen will not show any icons > > You need to follow step #3 properly to make sure that you are using lots of > memory. > > > [1] > http://dxr.allizom.org/mozilla-central/source/gfx/thebes/gfxContext.cpp#1532 > [2] > http://dxr.mozilla.org/mozilla-central/source/xpcom/base/nsCycleCollector. > cpp#4127 > [3] > http://dxr.mozilla.org/mozilla-central/source/ipc/chromium/src/base/ > message_pump_default.cc#56 As I said previously, the patch was fixing one of the issue I found while trying to debug this one. Now if you can reproduce that was likely an other bug that I found while using the steps to reproduce and the apps mentioned. Can you confirm that what you see on the screen is the exact same thing as https://bug1023796.bugzilla.mozilla.org/attachment.cgi?id=8438339 ? My question is do you have the text, but not the icons ? If yes, something that may happens is that we discard the image decoded data when the application is in background, and when the application goes to foreground we try to re-decode them again in order to display them. If we are out of memory at that point we may never paint them and wait forever. Sounds like a platform issue in this case. Moving from DOM:Apps -> Layout:Image to get the attention of the platform folks (in case you answer yes to my previous question).
Component: DOM: Apps → Layout: Images
Flags: needinfo?(21)
Updated•10 years ago
|
Flags: needinfo?(msreckovic) → needinfo?(milan)
Comment 50•10 years ago
|
||
(In reply to Lawrence Mandel [:lmandel] from comment #44) > In comment 35 aus states that this patch fixes the issue for him. Now that > the bug is on m-c, do any of the people who were able to reproduce (Vivien, > ddixon, loli, Josh) have access to a m-c build on which they can confirm > that they can no longer reproduce with the fix? Unable to reproduce issue using latest Flame 2.0, 2.1 and comment 39 STR. Device: Flame 2.0 Build ID: 20140629214227 Gaia: c0c8ad187c0466285f2580531e09f8322996f561 Gecko: d4dc609bcc8a Version: 32.0a2 (2.0) Firmware Version: v122 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Device: Flame Master Build ID: 20140630063630 Gaia: bc3bbf42d2a606f6b7038881cff5ec3795fdf953 Gecko: 3b46de297f3f Version: 33.0a1 (Master) Firmware Version: v122 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0
Flags: needinfo?(ddixon)
(In reply to Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) from comment #49) > (In reply to Tapas Kumar Kundu from comment #47) > > I found that homescreen main thread is waiting in > > > > IPDL::PContent::RecvFlushMemory > > gfxContext::Paint() [1] > > nsCycleCollector::Collect() [2] > > > > Homescreen spawned another IPC thread which is stuck in > > MessagePump::Wait()[3] > > > > Easy STR to reproduce this issue: > > 1) Flash build on device which is memory restricted to use only 256MB. > > 2) Copy lots of contents to sdcard and launch gallery. > > 3) You will see gallery is scanning images and now try to zoom in/out an > > image. This will force to use more memory and device will become slower > > 4) Minimize gallery and launch camcorder and try to record video > > 5) Stop recording video and Minimize camcorder. > > 6) Homescreen will not show any icons > > > > You need to follow step #3 properly to make sure that you are using lots of > > memory. > > > > > > [1] > > http://dxr.allizom.org/mozilla-central/source/gfx/thebes/gfxContext.cpp#1532 > > [2] > > http://dxr.mozilla.org/mozilla-central/source/xpcom/base/nsCycleCollector. > > cpp#4127 > > [3] > > http://dxr.mozilla.org/mozilla-central/source/ipc/chromium/src/base/ > > message_pump_default.cc#56 > > As I said previously, the patch was fixing one of the issue I found while > trying to debug this one. > > Now if you can reproduce that was likely an other bug that I found while > using the steps to reproduce and the apps mentioned. > > Can you confirm that what you see on the screen is the exact same thing as > https://bug1023796.bugzilla.mozilla.org/attachment.cgi?id=8438339 ? > This image contains text but in my case, I am not seeing any text on homescreen. > My question is do you have the text, but not the icons ? > I don't see any text or icon in homescreen when it happens. Homescreen is showing only background image. > If yes, something that may happens is that we discard the image decoded data > when the application is in background, and when the application goes to > foreground we try to re-decode them again in order to display them. > > If we are out of memory at that point we may never paint them and wait > forever. Sounds like a platform issue in this case. > Could you please help me to add logs in gecko so that I can confirm this theory ? I hope that this is the root cause. But I am not sure. So I need to confirm this theory.
Flags: needinfo?(21)
Comment 52•10 years ago
|
||
I an unable to repro this issue on Master. Environmental Variables: Device: Flame Master Build ID: 20140630040201 Gaia: de14e61098b742251b34f856e48649db8bed552c Gecko: b6408c32a170 Version: 33.0a1 (Master) Firmware Version: v122 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0
Flags: needinfo?(jschmitt)
Comment 53•10 years ago
|
||
(In reply to Ghislain Aus Lacroix [:aus] from comment #40) > Fabrice, I'll file a follow up to make this a locked operation. I filed bug 1032419
Assignee | ||
Comment 54•10 years ago
|
||
Chris, see comment #51 (https://bugzilla.mozilla.org/show_bug.cgi?id=1023796#c51). Is that something you could help with? Or help us send it to the right person? It doesn't feel like this is our bug anymore.
Flags: needinfo?(chrislord.net)
Comment 55•10 years ago
|
||
(In reply to Ghislain Aus Lacroix [:aus] from comment #54) > Chris, see comment #51 > (https://bugzilla.mozilla.org/show_bug.cgi?id=1023796#c51). Is that > something you could help with? Or help us send it to the right person? It > doesn't feel like this is our bug anymore. I'm afraid I don't really have anything valuable to add I don't think, this isn't an area I know much(/anything) about. My immediate thoughts are that there may be multiple issues conflated here. The homescreen isn't responsible for drawing the background, so if you see no icons and no text, likelihood is the homescreen either isn't running, or it encountered some kind of exception during startup and none of the data-stores have loaded. I'd rule out the simple things before diving into platform. If you do see just the text and no icons and the icons never show up, that sounds like a platform issue, but I'd be hard-pushed to pinpoint exactly where (and even then, it may still be a gaia issue with icon loading?). If the icons show up immediately after scrolling, I'd say it's a gfx issue, if they don't and we're assuming the issue isn't in Gaia, then it sounds like something further up the chain (layout, or widget perhaps?) There are too many comments here to really know what this bug is anymore (at least from my point of view), it could do with clarification of what the current status/problems are and perhaps splitting out into multiple bugs if there are multiple issues.
Flags: needinfo?(chrislord.net)
Updated•10 years ago
|
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+] [QAnalyst-Triage+] → [VH-FL-blocking-][VH-FC-blocking+][QAnalyst-Triage+][lead-review+]
Comment 56•10 years ago
|
||
Comment on attachment 8446010 [details] [diff] [review] memory-pressure-read-manifest-race.patch Aurora- The following results have been posted since the uplift request: master: ddixon can't reproduce (comment 50) Josh can't reproduce (comment 52) 2.0 (patch has not yet landed): Tapas can reproduce when cherrypicking this patch (comment 45) Loli can't reproduce (comment 48) ddixon can't reproduce (comment 50) Given the feedback, I'm not confident that this patch actually fixes the issue reported in the bug. There is also now an open question about whether this issue is platform related. If there is a good reason to take this patch even with the inconsistent feedback, please renom with a further explanation of why this patch should land on 2.0.
Attachment #8446010 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora-
Comment 57•10 years ago
|
||
Since this has landed on master, it appears this is fixed, unless I am missing something.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
Comment 58•10 years ago
|
||
Comment on attachment 8446010 [details] [diff] [review] memory-pressure-read-manifest-race.patch Review of attachment 8446010 [details] [diff] [review]: ----------------------------------------------------------------- (In reply to Lawrence Mandel [:lmandel] from comment #56) > Comment on attachment 8446010 [details] [diff] [review] > memory-pressure-read-manifest-race.patch > 2.0 (patch has not yet landed): > Tapas can reproduce when cherrypicking this patch (comment 45) I am going to re-nominate this issue as I believe if you read comment 49 clearly, the issue that Tapas is seeing is a different issue than the one solved here. (Text vs no text is a big difference). This bug is solving an issue where we would not have the proper information in app manifests, and the issue where there is no text appears to be something else.
Attachment #8446010 -
Flags: approval-mozilla-aurora- → approval-mozilla-aurora?
Updated•10 years ago
|
Component: Layout: Images → DOM: Apps
(In reply to Kevin Grandon :kgrandon from comment #58) > Comment on attachment 8446010 [details] [diff] [review] > memory-pressure-read-manifest-race.patch > > Review of attachment 8446010 [details] [diff] [review]: > ----------------------------------------------------------------- > > (In reply to Lawrence Mandel [:lmandel] from comment #56) > > Comment on attachment 8446010 [details] [diff] [review] > > memory-pressure-read-manifest-race.patch > > 2.0 (patch has not yet landed): > > Tapas can reproduce when cherrypicking this patch (comment 45) > > I am going to re-nominate this issue as I believe if you read comment 49 > clearly, the issue that Tapas is seeing is a different issue than the one > solved here. (Text vs no text is a big difference). This bug is solving an > issue where we would not have the proper information in app manifests, and > the issue where there is no text appears to be something else. Do you want me to open a new bug for my observation in #comment 47 and #comment 51 ? Please let me know . This is blocking all our testing and it is very urgent issue for us.
Flags: needinfo?(kgrandon)
Comment 60•10 years ago
|
||
(In reply to Tapas Kumar Kundu from comment #59) > (In reply to Kevin Grandon :kgrandon from comment #58) > > Comment on attachment 8446010 [details] [diff] [review] > > memory-pressure-read-manifest-race.patch > > > > Review of attachment 8446010 [details] [diff] [review]: > > ----------------------------------------------------------------- > > > > (In reply to Lawrence Mandel [:lmandel] from comment #56) > > > Comment on attachment 8446010 [details] [diff] [review] > > > memory-pressure-read-manifest-race.patch > > > 2.0 (patch has not yet landed): > > > Tapas can reproduce when cherrypicking this patch (comment 45) > > > > I am going to re-nominate this issue as I believe if you read comment 49 > > clearly, the issue that Tapas is seeing is a different issue than the one > > solved here. (Text vs no text is a big difference). This bug is solving an > > issue where we would not have the proper information in app manifests, and > > the issue where there is no text appears to be something else. > > Do you want me to open a new bug for my observation in #comment 47 and > #comment 51 ? > > Please let me know . This is blocking all our testing and it is very urgent > issue for us. Yes, I'm not sure if there is a bug filed yet, but let's file a new one and track that issue in the new bug. If there's a dupe we'll mark it as such. Thanks!
Flags: needinfo?(kgrandon)
new bug 1033618 is created for #comment 47 and #comment 51
Comment 62•10 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/2eae9f045dfe
status-firefox31:
--- → wontfix
Keywords: leave-open
Comment 63•10 years ago
|
||
Comment on attachment 8446010 [details] [diff] [review] memory-pressure-read-manifest-race.patch Hmm, so I closed this because we had a patch that fixed the main issue we were seeing, and I guess this got uplifted because it was blocking. Hope this didn't mess anything up. Let's track the missing icon issue in bug 1033618. Thanks all!
Attachment #8446010 -
Flags: approval-mozilla-aurora?
Assignee | ||
Comment 64•10 years ago
|
||
Going to go ahead and clear the NI? requests here since we're tracking everything in bug 1033618. If NI? still necessary, please flag those people in that bug.
Flags: needinfo?(milan)
Flags: needinfo?(21)
Assignee | ||
Updated•10 years ago
|
Whiteboard: [caf priority: p1][systemsfe][CR 686636] → [caf priority: p1][systemsfe][CR 686636][p=5]
Reporter | ||
Comment 65•10 years ago
|
||
Tested and working: 2.1 Hamachi Gecko-a777777 Gaia-049853b 2.0 Hamachi Gecko-d3eae03 Gaia-ef67af2
Status: RESOLVED → VERIFIED
Updated•6 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•