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

Status: VERIFIED WORKSFORME

(Core :: Graphics, defect)

Description

[KTucker [:KTucker][Inactive 3/4/2016]]

Attachment: 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)

Comment 1

[KTucker [:KTucker][Inactive 3/4/2016]]

This issue does not occur on v1.1

Comment 2

[KTucker [:KTucker][Inactive 3/4/2016]]

Attachment: Screenshot

Comment 3

[Sarah Parsons]

Per bug 915868 there is no regression window because this issue has affected all Buri 1.2 builds.

Comment 4

[Nicolas Silva [:nical]]

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).

Comment 5

[Benoit Jacob [:bjacob] (mostly away)]

Had forgotten about this bug, sorry. Looking into it.

Comment 6

[Benoit Jacob [:bjacob] (mostly away)]

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.

Comment 7

[Benoit Jacob [:bjacob] (mostly away)]

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).

Comment 9

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: Gralloc / layers dump at the time of the out-of-pmem condition, using patch from bug 916626

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.

Comment 10

[Benoit Jacob [:bjacob] (mostly away)]

Re-self-assigning, I guess, as there seems to be abnormal gralloc usage here, which should be actionable...

Comment 11

[Milan Sreckovic [:milan] (needinfo for best results)]

I'll un-dupe it then.

Comment 12

[Benoit Jacob [:bjacob] (mostly away)]

Attachment: Gralloc / layers dump at the time of the out-of-pmem condition, using patch from bug 916626

New version of the gralloc/layers dump using _updated_ patch on bug 916626. The previous one had a wrong layer tree.

Comment 13

[Benoit Jacob [:bjacob] (mostly away)]

(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.

Comment 14

[Benoit Jacob [:bjacob] (mostly away)]

Sotaro, given our current understanding of pmem, do you think that this bug is actionable for B2G 1.2? What can be done?

Comment 15

[Sotaro Ikeda [:sotaro]]

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.

Comment 17

[Jason Smith [:jsmith]]

Dependency is fixed. Can we retest?

Comment 18

[Sarah Parsons]

This issue still reproduces on Buri 1.2 Build ID: 20131031004003

Gaia   df049e3177ced0ca493ff0d192c65f18392bb462
SourceStamp 93eafd042c1c
BuildID 20131031004003
Version 26.0

Comment 19

[Sarah Parsons]

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

Comment 20

[Jason Smith [:jsmith]]

What about 1.3?

Comment 21

[Sarah Parsons]

This issue reproduces on the Buri 1.3 Build ID: 20131101040203

Gaia   ccdf357ea150fc7d8b8a4b74c7adf31e7a57e465
SourceStamp abe6790a5dd8
BuildID 20131101040203
Version 28.0a1

Comment 22

[Milan Sreckovic [:milan] (needinfo for best results)]

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).

Comment 23

[Sotaro Ikeda [:sotaro]]

./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.

Comment 24

[Jason Smith [:jsmith]]

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.

Comment 25

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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

Comment 26

[Sotaro Ikeda [:sotaro]]

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}}

Comment 27

[Sotaro Ikeda [:sotaro]]

(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

Comment 28

[Sotaro Ikeda [:sotaro]]

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

Comment 29

[Sotaro Ikeda [:sotaro]]

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.

Comment 30

[Sotaro Ikeda [:sotaro]]

(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.

Comment 31

[Sotaro Ikeda [:sotaro]]

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.

Comment 32

[Preeti Raghunath(:Preeti)]

Naoki,

Please check is this works with the new ROM.

Comment 33

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

It seems to be working with the new OEM build:
V1.2_US_20131115.cfg