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)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.0+, firefox31 wontfix, firefox32 fixed, firefox33 fixed, b2g-v2.0 fixed, b2g-v2.1 fixed)

VERIFIED FIXED
2.0 S5 (4july)
blocking-b2g 2.0+
Tracking Status
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)

Attached image 2014-06-11-11-23-34.png
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
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
Whiteboard: [systemsfe]
Let's try to get logs here as Cristian suggests & confirm the 25% reproducibility.
Keywords: qawanted
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
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 → ---
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
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)
Using one of the dupe's STRs, let's get a logcat.
Keywords: qawanted
blocking-b2g: 2.0? → 2.0+
Whiteboard: [systemsfe] → [systemsfe][MemShrink]
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.
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.
(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.
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.
(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 ago10 years ago
Resolution: --- → WORKSFORME
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.
And since Bug 1019693 is consistently reproducible, the vertical homescreen with no icon issue is consistently reproducible as well.
(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 → ---
Blocks: 1015336
No longer blocks: vertical-homescreen
Aus - any chance you have a hamachi and want to investigate this tricky one?
Flags: needinfo?(aus)
Attached file log.txt
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%
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+] → [VH-FL-blocking-][VH-FC-blocking+][QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Issue occurred on 2.1 Flame

Environmental Variables:
Device: Flame
Build ID: 20140618040513
Gaia: 431aed0a7c7560c6eacd35ea69aa0a7a4ebe72c7
Gecko: 37f08ddaea48
Version: 33.0a1  
Firmware Version: v121-2
Flags: needinfo?(jmitchell)
Yep, I'll find a Hamachi here in Taipei and have a look...
Flags: needinfo?(aus)
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?
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)
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)
(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.
: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.
(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
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.
After this has happened, tapping anywhere on the homescreen produces:

I/Gecko   (  921): ###!!! [Parent][MessageChannel] Error: Channel error: cannot send/recv
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
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+][QAnalyst-Triage?] → [VH-FL-blocking-][VH-FC-blocking+]
Note for qawanted - we also need an updated logcat w/console enabled. The logcat included here doesn't have that.
Whiteboard: [systemsfe][MemShrink] → [systemsfe]
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.
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.
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)
(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!
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)
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 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+
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
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+] [QAnalyst-Triage?] → [VH-FL-blocking-][VH-FC-blocking+] [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
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.
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?
Keywords: leave-open
Blocks: 1031503
Whiteboard: [systemsfe] → [systemsfe][CR 686636]
No longer blocks: 1031503
Whiteboard: [systemsfe][CR 686636] → [caf priority: p1][systemsfe][CR 686636]
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
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
Flags: needinfo?(msreckovic)
(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)
(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)
Flags: needinfo?(msreckovic) → needinfo?(milan)
(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)
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)
(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
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)
(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)
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+] [QAnalyst-Triage+] → [VH-FL-blocking-][VH-FC-blocking+][QAnalyst-Triage+][lead-review+]
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-
Since this has landed on master, it appears this is fixed, unless I am missing something.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
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?
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)
(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)
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?
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)
Whiteboard: [caf priority: p1][systemsfe][CR 686636] → [caf priority: p1][systemsfe][CR 686636][p=5]
Tested and working:
2.1
Hamachi
Gecko-a777777
Gaia-049853b

2.0
Hamachi
Gecko-d3eae03
Gaia-ef67af2
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: