Closed Bug 918062 Opened 6 years ago Closed 6 years ago

[B2G][Buri][Contacts][Gallery] Crop does not load the image selected from the gallery when adding a contact picture

Categories

(Core :: Graphics, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

()

VERIFIED WORKSFORME
blocking-b2g koi+

People

(Reporter: KTucker, Assigned: bjacob)

References

Details

(Keywords: regression, Whiteboard: permafail)

Attachments

(3 files, 1 obsolete file)

Attached file logcat
Description:
If a user selects to add a gallery picture for a contact, crop will appear with a black screen. The gallery image will will never load.

Repro Steps:
1)  Updated to Buri Build ID: 20130916040205
2)  Tap the "Contacts" icon. 
3)  Tap on any contact.
4)  Tap on the "Edit Contact" button in the top right-hand corner.
5)  Tap on the "Add Picture" box.
6)  Tap on the "Gallery" button.
7)  Tap on a any gallery picture.

Actual:
The user is taken to an empty black crop screen. The gallery image is not loaded.

Expected:
The user is able to crop the selected gallery image and add it as the contact's picture.

Environmental Variables
Gecko: http://hg.mozilla.org/mozilla-central/rev/c4bcef90cef9
Gaia: a0079597d510ce8ea0b9cbb02c506030510b9eeb
Platform Version: 26.0a1

Notes:
Repro frequency: (100%)
See attached: (screenshot,logcat)
This issue does not occur on v1.1
Attached image Screenshot
QA Contact: sparsons
Per bug 915868 there is no regression window because this issue has affected all Buri 1.2 builds.
Blocks: GFXB2G1.2
blocking-b2g: --- → koi?
Component: Gaia::Contacts → Graphics
Product: Boot2Gecko → Core
Version: unspecified → Trunk
I can't reproduce the error on my Unagi device, but fyi, this looks like a WebGL bug (either in WebGL itself or in the compositing code path that is used by WebGL).
Assignee: nobody → bjacob
blocking-b2g: koi? → koi+
Had forgotten about this bug, sorry. Looking into it.
I just reproduced this on:

 mozilla-aurora changeset 75e1f0a7290c  (Sep 28)
 B2G v1.2 branch
 config: hamachi
 device: hamachi

The first time I followed the STR in comment 0, I didn't reproduce the bug.

But then I went back to the contact app's default screen, killed all open applications, and followed again the STR. That reproduced.

In logcat:

I/Gecko   ( 2287): Attempting load of libEGL.so
I/Adreno200-EGL( 2287): <qeglDrvAPI_eglInitialize:295>: EGL 1.4 QUALCOMM build:  (Merge)
I/Adreno200-EGL( 2287): Build Date: 06/06/13 Thu
I/Adreno200-EGL( 2287): Local Branch: b2g_autogen_ephemeral_branch
I/Adreno200-EGL( 2287): Remote Branch: 
I/Adreno200-EGL( 2287): Local Patches: 
I/Adreno200-EGL( 2287): Reconstruct Branch: 
I/Gecko   ( 2287): OpenGL version detected: 200
I/Gecko   ( 2287): SharedSurface_Gralloc::Create -------
E/memalloc( 1985): /dev/pmem: No more pmem available
E/msm7627a.gralloc( 1985): gralloc failed err=Out of memory
W/GraphicBufferAllocator( 1985): alloc(300, 390, 1, 00000300, ...) failed -12 (Out of memory)
E/GeckoConsole( 2287): [JavaScript Warning: "Error: WebGL: Can't get a usable WebGL context" {file: "app://gallery.gaiamobile.org/js/ImageEditor.js" line: 1151}]
E/GeckoConsole( 2287): [JavaScript Error: "TypeError: gl is null" {file: "app://gallery.gaiamobile.org/js/ImageEditor.js" line: 1154}]
D/HWComposer( 1985): Frame rendered

Now dumping the pmem memory mapping for the b2g main process:

bjacob:/hack/mozilla-aurora$ adb shell b2g-ps
APPLICATION      USER     PID   PPID  VSIZE  RSS     WCHAN    PC         NAME
b2g              root      1985  159   180620 63312 ffffffff 400e95e0 S /system/b2g/b2g
Homescreen       app_2059  2059  1985  74304  26772 ffffffff 400405e0 S /system/b2g/plugin-container
Communications   app_2263  2263  1985  78404  35208 ffffffff 4004b5e0 S /system/b2g/plugin-container
(Preallocated a  root      2303  1985  67008  25208 ffffffff 401085e0 S /system/b2g/plugin-container
bjacob:/hack/mozilla-aurora$ adb shell cat /proc/1985/maps | grep pmem
4859f000-48d9f000 rw-s 0c400000 00:0b 2416       /dev/pmem

The difference (0x48d9f000 - 0x4859f000) is exactly 8 M, so we've indeed maxed out the available pmem on hamachi.
This being a case of "we do not currently fail gracefully in out-of-pmem situations on b2g 1.2", let's block this on bug 905882.

Also, unassigning myself from this bug (nothing to be done here, but fix 905882).
Assignee: bjacob → nobody
Depends on: 905882
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 905882
This page shows the list of gralloc buffers and the layer tree at the time of the out-of-pmem condition. We indeed have over 7 M of gralloc buffers (18 of them). Lots of them clearly shouldn't have been kept around. Also, the layer tree only references 2 of them.
Re-self-assigning, I guess, as there seems to be abnormal gralloc usage here, which should be actionable...
Assignee: nobody → bjacob
I'll un-dupe it then.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
New version of the gralloc/layers dump using _updated_ patch on bug 916626. The previous one had a wrong layer tree.
Attachment #812244 - Attachment is obsolete: true
(In reply to Benoit Jacob [:bjacob] from comment #9)
> Also, the
> layer tree only references 2 of them.

That was false, sorry. All the gralloc buffers there are referenced from the layer tree.
Whiteboard: burirun1 → burirun1, burirun2
Sotaro, given our current understanding of pmem, do you think that this bug is actionable for B2G 1.2? What can be done?
Flags: needinfo?(sotaro.ikeda.g)
out of pmem problem is going to be fixed in Bug 905882. Right now, waiitng the patches landed on CAF. After that is going to enable it on moz build. And need to ask to enable it also on partners.

But general out of memory problem is still present. We need to test about it after the fallback is enabled.
Flags: needinfo?(sotaro.ikeda.g)
Duplicate of this bug: 929240
Whiteboard: burirun1, burirun2 → burirun1, burirun2, burirun3
Dependency is fixed. Can we retest?
Keywords: qawanted
This issue still reproduces on Buri 1.2 Build ID: 20131031004003

Gaia   df049e3177ced0ca493ff0d192c65f18392bb462
SourceStamp 93eafd042c1c
BuildID 20131031004003
Version 26.0
Keywords: qawanted
I just checked on Buri 1.2 Build ID: 20131101004000 and it still reproduces. 

Gaia   e717aec947571f5daf923c040a82f9f0719bb526
SourceStamp 54de309e18a9
BuildID 20131101004000
Version 26.0



(In reply to Sarah Parsons from comment #18)
> This issue still reproduces on Buri 1.2 Build ID: 20131031004003
> 
> Gaia   df049e3177ced0ca493ff0d192c65f18392bb462
> SourceStamp 93eafd042c1c
> BuildID 20131031004003
> Version 26.0
What about 1.3?
Keywords: qawanted
This issue reproduces on the Buri 1.3 Build ID: 20131101040203

Gaia   ccdf357ea150fc7d8b8a4b74c7adf31e7a57e465
SourceStamp abe6790a5dd8
BuildID 20131101040203
Version 28.0a1
Keywords: qawanted
Just to be clear, you're flashing the phone with "flash.sh -f", right?  The fix is outside of Gecko+Gaia, so the default flash will not pick it up.  Also, as I understand, this only got uplifted to 1.2 on Friday (Nov 1).
./flash.sh -f is not a recommended way(but I use it always) to flash ROMs. It seems better to wait hamachi's base image be updated.
Whiteboard: burirun1, burirun2, burirun3 → permafail
QA Wanted - we have a base 1.2 image with non-working wifi, but that should allow us to verify if this works now or not.
Keywords: qawanted
Gaia:     377eb71506d8790d3c3280d82ac007ff4525b7e0
Gecko:    c15f5d7e0d7ebff5f8edef0745f144cd1552e34c
BuildID   20131112123250
Version   28.0a1
Base Build : US_V1.2_20131111.cfg
Buri

Cropping still causes the image not to appear in the 1.2 build

11-12 14:09:26.519: W/memalloc(137): Falling back to ashmem
11-12 14:09:26.579: I/Gecko(1522): SharedSurface_Gralloc::Create: success -- surface 0x43996100, GraphicBuffer 0x441baa80.
11-12 14:09:27.779: I/Gecko(137): ###!!! [Parent][MessageChannel] Error: Channel error: cannot send/recv
11-12 14:09:28.019: I/Gecko:ProcessPriorityManager(137): [Gallery, child-id=20, pid=1522] Scheduling reset timer to fire in 1000ms.
11-12 14:09:28.039: I/Gecko:ProcessPriorityManager(137): [Gallery, child-id=20, pid=1522] ScheduleResetPriority bailing; the timer is already running.
11-12 14:09:28.039: I/Gecko:ProcessPriorityManager(137): [child-id=20, pid=-1] Destroying ParticularProcessPriorityManager.
11-12 14:09:28.349: E/copybit(137): copyBits failed (Invalid argument)
11-12 14:09:28.349: E/copybit(137): 0: src={w=0, h=1217636992, f=1217457952, rect={1217457952,1121590480,1075253320,1217743024}}
11-12 14:09:28.349: E/copybit(137):     dst={w=320, h=480, f=14, rect={319,20,1,460}}
11-12 14:09:28.349: E/copybit(137):     flags=00000100
11-12 14:09:28.349: E/msm7627a.hwcomposer(137): hwc_set: Copybit layer draw failed!
11-12 14:09:28.369: D/HwcUtils(137): Skip layer
Flags: needinfo?(sotaro.ikeda.g)
Keywords: qawanted
Thanks for the confirmation. The fallback seems happen correctly. There seems two suspicious poing.

- [1] Even when fallback happens, hw composer seems to be used for fallbacked buffer. Only OpenGL could render it correctly. But it is not clear form the log. Just one possibility.
- [2] The following log seems incorrect.
  > src={w=0, h=1217636992, f=1217457952, rect={1217457952,1121590480,1075253320,1217743024}}
Flags: needinfo?(sotaro.ikeda.g)
(In reply to Sotaro Ikeda [:sotaro] from comment #26)
> Thanks for the confirmation. The fallback seems happen correctly. There
> seems two suspicious poing.
> 
> - [1] Even when fallback happens, hw composer seems to be used for
> fallbacked buffer. Only OpenGL could render it correctly. But it is not
> clear form the log. Just one possibility.

If [1] is the cause of the problem. Following change is not applied to the ROM.

https://www.codeaurora.org/cgit/quic/la/platform/hardware/qcom/display/commit/?h=b2g_ics_1.2&id=be8edec21365db5fd27f34e72b1bacea28453214
Naoki, did you see the following log in the logcat?

> E msm7627a.hwcomposer: hwc_set: Unable to render by hwc due to non-pmem memory
> HWComposer: H/W Composition failed
> E msm7627a.hwcomposer: hwc_set: Unable to render by hwc due to non-pmem memory
> E HWComposer: H/W Composition failed
Flags: needinfo?(nhirata.bugzilla)
When I build b2g v1.2 hamachi ROM by myself and flash the ROM by using "./flash.sh -f", I confirmed the success of STR in Comment 0. And saw log in Comment 28 in logcat.
Flags: needinfo?(nhirata.bugzilla)
(In reply to Sotaro Ikeda [:sotaro] from comment #28)
> Naoki, did you see the following log in the logcat?
> 
> > E msm7627a.hwcomposer: hwc_set: Unable to render by hwc due to non-pmem memory
> > HWComposer: H/W Composition failed
> > E msm7627a.hwcomposer: hwc_set: Unable to render by hwc due to non-pmem memory
> > E HWComposer: H/W Composition failed

I flashed the updated ROM on hamachi and saw the above log.
I flashed the updated ROM on hamachi. When I tried the STR in Comment 0 by using a picture taken by hamachi, I did not see the problem.
Naoki,

Please check is this works with the new ROM.
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Flags: needinfo?(nhirata.bugzilla)
Resolution: --- → WORKSFORME
It seems to be working with the new OEM build:
V1.2_US_20131115.cfg
Flags: needinfo?(nhirata.bugzilla)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.