894826 - [Buri][Gallery] Multiple taps on image edit ok button causes gallery to crash

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Gallery, defect, P1)

Description

[sync-1]

AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.152
 Firefox os  v1.1
 Mozilla build ID:20130702230206
 
 Created an attachment (id=459458)
 Logcat
 
 DEFECT DESCRIPTION:
  The MS always crash when save picture edited
  REPRODUCING PROCEDURES:
  1.Launch Gallery app
  2.select one picture to view
  3.Edit the pic
  4.Change its Exposure,press finish button->MS crash->ko
  操作步骤：
  1.进入Gallery
  2.选择一张图片查看
  3.编辑这张图片
  4.调整图片的曝光度，点击完成->手机回到Idle->ko
  EXPECTED BEHAVIOUR:
  It should finish correctly
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
  Mid
  REPRODUCING RATE:
  3/5
  For FT PR, Please list reference mobile's behavior:

Comment 1

[sync-1]

Clone from brother

Comment 2

[sync-1]

Clone from brother

Comment 3

[sync-1]

Attachment: Logcat

Comment 4

[buri.blff]

another reproducing procedures is this:1. Launch Gallery app 2.select one picture to view 3.Edit the pic 4.click its crop,then click undo button server times 5.click OK button sometimes, the gallery app will closed--->KO.

Comment 5

[David Flanagan [:djf]]

What is "MS"? Is that Media Server?  If so, I think that the component is wrong and this is a gecko bug not a gaia bug.  (Comment 4 sounds like a bug in the Gallery app, but I can't tell from whether the initial bug description is about Gallery or about something in gecko)

Sotaro, does this bug report make any sense to you?

Comment 6

[buri.blff]

(In reply to David Flanagan [:djf] (PTO 7/3-7/19) from comment #5)
> What is "MS"? Is that Media Server?

Hi David, The "MS" means firefox os phone,not Meaia Server.

Comment 7

[John Hu [:johnhu][:johu][:醬糊小弟]]

With the STR of description, gallery app can change the exposure but very slow. If we tap the ok button multiple times when editing exposure, gallery app crashes with the following error in logcat:

E/GeckoConsole(  742): [JavaScript Warning: "Error: WebGL: Exceeded 2 live WebGL contexts for this principal, losing the least recently used one." {file: "app://gallery.gaiamobile.org/js/ImageEditor.js" line: 1123}]

And followed by:
I/Gecko   (  111): 
I/Gecko   (  111): ###!!! [Parent][AsyncChannel] Error: Channel error: cannot send/recv
I/Gecko   (  111):
...
E/GeckoConsole(  111): [JavaScript Error: "[Exception... "'Error: no message manager set' when calling method: [nsIObserver::observe]"  nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)"  location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0"  data: no]"]



I don't know why but I can't reproduce the bug in comment 4.

Comment 8

[Sotaro Ikeda [:sotaro]]

I succeededd to generate only comment #7. In this case, Gallery app is killed by low memory. Following is a related "adb shell dmesg" log.

<4>[  212.670478] select 350 (Usage), adj 6, size 4544, to kill
<4>[  212.670498] select 477 (Camera), adj 6, size 4711, to kill
<4>[  212.670514] send sigkill to 477 (Camera), adj 6, size 4711
<4>[  212.860243] select 350 (Usage), adj 6, size 4534, to kill
<4>[  212.860269] send sigkill to 350 (Usage), adj 6, size 4534
<7>[  213.174868] ygg *******msm_batt_worker 1388
<4>[  215.690753] select 613 ((Preallocated a), adj 6, size 3367, to kill
<4>[  215.690778] send sigkill to 613 ((Preallocated a), adj 6, size 3367
<1>[  216.936799] ####taos_irq####
<6>[  216.937821] prox before taos_check_and_report: status 0x13
<6>[  216.938484] als taos_check_and_report: status 0x13
<1>[  217.236309] ####taos_irq####
<6>[  217.237341] prox before taos_check_and_report: status 0x13
<6>[  217.237998] als taos_check_and_report: status 0x13
<4>[  218.572796] select 398 (Homescreen), adj 4, size 3384, to kill
<4>[  218.572848] send sigkill to 398 (Homescreen), adj 4, size 3384
<4>[  219.202626] select 522 (Gallery), adj 2, size 19363, to kill
<4>[  219.202648] send sigkill to 522 (Gallery), adj 2, size 19363

Comment 9

[Sotaro Ikeda [:sotaro]]

sync-1, can you get "adb shell dmesg" log when the problem happens? And also adb shell again?

Comment 10

[Sotaro Ikeda [:sotaro]]

(In reply to David Flanagan [:djf] (PTO 7/3-7/19) from comment #5)
> What is "MS"? Is that Media Server?  If so, I think that the component is
> wrong and this is a gecko bug not a gaia bug.  (Comment 4 sounds like a bug
> in the Gallery app, but I can't tell from whether the initial bug
> description is about Gallery or about something in gecko)
> 
> Sotaro, does this bug report make any sense to you?

This bug seems that Gallary app is killed by low memory.

Comment 11

[Justin Lebar (not reading bugmail)]

See https://wiki.mozilla.org/B2G/Debugging_OOMs for important steps to follow when debugging an OOM.

Comment 12

[Sotaro Ikeda [:sotaro]]

sync-1, can you analyze the problem if it is oom problem by following the link in Comment 11?

Comment 13

[buri.blff]

Attachment: dmsg.txt

Comment 14

[buri.blff]

(In reply to Sotaro Ikeda [:sotaro] from comment #9)
> sync-1, can you get "adb shell dmesg" log when the problem happens? And also
> adb shell again?

Hi attachment 779559 [details] is the dmesg logs, please check. Thanks.

Comment 15

[buri.blff]

(In reply to Sotaro Ikeda [:sotaro] from comment #12)
> sync-1, can you analyze the problem if it is oom problem by following the
> link in Comment 11?

Maybe it is oom problem. from dmesg, we could find logs like this: 
<3>[ 1705.587679] Out of memory: Kill process 1388 (Gallery) score 499 or sacrifice child
<3>[ 1705.587698] Killed process 1388 (Gallery) total-vm:183844kB, anon-rss:51076kB, file-rss:16028kB

Comment 16

[Justin Lebar (not reading bugmail)]

This is the OOM killer, not to be confused with the low-memory killer (LMK).

The OOM killer runs when we're /really/ out of memory.  When the LMK is functioning properly, the OOM killer should rarely if ever run.  The one time when we expect the OOM killer to run is when an app makes a very big allocation.

Looking at this dmesg log, it appears that there's plenty of RAM available at the time of the crash.  So my best guess is that the gallery is indeed making a very big allocation.  The stack in the log is suggestive:

> (unwind_backtrace+0x0/0x12c) from [<c0138f04>] (warn_alloc_failed+0xe4/0x108)
> (warn_alloc_failed+0xe4/0x108) from [<c0139594>] (__alloc_pages_nodemask+0x5cc/0x6ac)
> (__alloc_pages_nodemask+0x5cc/0x6ac) from [<c02e0230>] (_kgsl_sharedmem_page_alloc+0xec/0x330)
> (_kgsl_sharedmem_page_alloc+0xec/0x330) from [<c02da698>] (kgsl_ioctl_gpumem_alloc+0xa0/0x190)
> (kgsl_ioctl_gpumem_alloc+0xa0/0x190) from [<c02db3a0>] (kgsl_ioctl+0x1dc/0x2ac)
> (kgsl_ioctl+0x1dc/0x2ac) from [<c017586c>] (do_vfs_ioctl+0x500/0x57c)
> (do_vfs_ioctl+0x500/0x57c) from [<c017591c>] (sys_ioctl+0x34/0x54)
> (sys_ioctl+0x34/0x54) from [<c0042d60>] (ret_fast_syscall+0x0/0x30)

I'm not totally sure how to read this, but it seems like someone is trying to
allocate pages, and then the alloc is failing.

As a next step, I'd run this testcase in gdb and see if you can get a better
backtrace.

* Start the gallery app on the phone.

* $ adb shell b2g-ps
  Note the pid of the gallery app

* $ ./run-gdb.sh attach <pid>

* Cause the crash

* (gdb) bt

Comment 17

[bhavana bajaj [:bajaj]]

Adding needinfo on sync-1 to help with more info here giving us specifics on the size of the image etc that is being saved.

Comment 18

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

Possible dup of bug 832511?  Any edit to a large image may cause an OOM.

Comment 19

[Jason Smith [:jsmith]]

QA Wanted - We should try to reproduce this bug with pictures derived from different sources - via the camera or sdcard. For pictures with the sdcard, try reproducing this bug with pictures of varying sizes.

Comment 20

[Natalya Kot [:nkot]]

Attachment: image, 1.57MB

was able to reproduce this bug only with very large images (1.57MB, 1.75MB, 3.74MB),
could not reproduce it with smaller images, imported or camera taken 

Buri
Build ID: 20130702230206
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/a078412b1671
Gaia: a890df3624df350574cb942d13711e1d858118d3
Platform Version: 18.1

Comment 21

[Jason Smith [:jsmith]]

Okay. On that regard since this is reproducing with large images, I'm duping against bug 832511.

Comment 22

[Ray REN]

Attachment: IMG_152K

Comment 23

[Ray REN]

(In reply to bhavana bajaj [:bajaj] from comment #17)
> Adding needinfo on sync-1 to help with more info here giving us specifics on
> the size of the image etc that is being saved.

We use any images can reproduce, like attachment 784172 [details], only 152K.

Comment 24

[Jason Smith [:jsmith]]

Okay. So if this reproduces on 152 KB picture, then this isn't a dupe of that bug.

Comment 25

[Justin Lebar (not reading bugmail)]

The compressed size of the image has nothing to do with how much memory the image uses when uncompressed.  You can make a /giant/ 4kb PNG, for example.

Comment 26

[Ray REN]

(In reply to Justin Lebar [:jlebar] from comment #25)
> The compressed size of the image has nothing to do with how much memory the
> image uses when uncompressed.  You can make a /giant/ 4kb PNG, for example.

I can't reproduce with PNG images, Even it more than 200KB.

Comment 27

[Jason Smith [:jsmith]]

The image in question here appears to be 1200 x 1600. 

Here's an easy way we can figure out if this is a dupe or not - can someone try testing this with the attached image (https://bugzilla.mozilla.org/attachment.cgi?id=784172) and see what crash report URL we get?

Comment 28

[Jason Smith [:jsmith]]

Can't reproduce a crash with the provided image on b2g18 unagi 8/1 build. Trying Buri next.

Comment 29

[Jason Smith [:jsmith]]

Not getting a crash with the provided image on a Buri 7/25 partner build either.

Comment 30

[bhavana bajaj [:bajaj]]

Given our QA is not able to reproduce the issue on the latest build on a couple of devices, can you please try that ?We think you are on an old build which may be the issue here.

Comment 31

[Ray REN]

Our latest build is 
AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.171
Firefox os  v1.1
Mozilla build ID:20130722070207

and it exist. We need serveral days to get newest build. If we got new build(after 7/25), I will give feedback soon.

Comment 32

[Lukas Blakk [:lsblakk] use ?needinfo]

The device is not intended for image editing of images put onto the camera via sdcard and since comment 20 states this cannot be reproduced with camera-taken images this is not a blocker for v1.1

Comment 33

[Jack Liu]

mark leo? for it is still very easy to reproduce on Mozilla build ID:20130806071254.
1. just edit a picture no matter the size.
2. press the button on top-right 2 or more times quickly.
3. gallery will crash.

Comment 34

[Andrew Overholt [:overholt]]

QA, can you see if you can reproduce the multiple tapping issue and get more info if so?

Comment 35

[Natalya Kot [:nkot]]

Attachment: logcat 1

it is reproducible, but it rather exits the app not crashing it..

STR: 
just tapping repetitively the checkbox icon in edit-photo will exit the app

Buri:US_20130808
Build ID: 20130821041204
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/0c8931d85f0a
Gaia: 849cee8a3ee5a2a6f4e39183549d36c3acc05f2f
Platform Version: 18.1

Comment 36

[Dietrich Ayala (:dietrich)]

(In reply to nkot from comment #35)
> Created attachment 793606 [details]
> logcat  1
> 
> it is reproducible, but it rather exits the app not crashing it..

Is this with photos taken with the camera app? Or other?

Comment 37

[Natalya Kot [:nkot]]

(In reply to Dietrich Ayala (:dietrich) from comment #36)
> Is this with photos taken with the camera app? Or other?

it's happening with both, imported and camera-taken photos

1. tap repetitively on the checkbox icon in edit-photo
==> gallery closes
2. longpress home button to open cards view
==> gallery is not there

Comment 38

[Ray REN]

I think this could fixed like this: When user click OK button, we should make it unuseful until it save successfully.

Comment 39

[Preeti Raghunath(:Preeti)]

QA, please confirm if this bug was working in 1.0.1.

Comment 40

[dkumar]

Issue does not reproduce on unagi v1.0.1 and was working just fine.
 
Environmental Variables
Build ID: 20130821043202
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/9c62297d11b0
Gaia: 054cdc27404e2daca91d3065d9783681032b2151
Platform Version: 18.0

The app does not crash or exit.

Comment 41

[Preeti Raghunath(:Preeti)]

So this is a regression for 1.1?
Hema,

Please check if this belongs in your team.

Comment 42

[bhavana bajaj [:bajaj]]

Given this is a reproducible, regression and is posssible users can hit this day-day so leo+

Comment 43

[David Flanagan [:djf]]

Leo has been really good about testing repetitive taps and has found several bugs in the camera that way.  This looks like another.

I'm guessing that each time the user clicks the Save button, we create an edited version of the image, which allocates a lot of memory. So I'm hoping that all we need to do to fix this is to disable the Save button after the user taps it the first time.

Diego: this might be a very easy fix for a long-standing crasher.  Want to take it?

Comment 44

[Diego Marcos [:dmarcos]]

Sure. I'll take this one

Comment 45

[Diego Marcos [:dmarcos]]

Attachment: pullRequest.html

Comment 46

[Diego Marcos [:dmarcos]]

Comment on attachment 799847 [details]
pullRequest.html

<html>
<head>
<meta http-equiv="Refresh" content="1;url=https://github.com/mozilla-b2g/gaia/pull/11935/">
</head>
<body>
<a href="https://github.com/mozilla-b2g/gaia/pull/11935/s">Redirecting to github.</a>
</body>
</html>

Comment 47

[Diego Marcos [:dmarcos]]

Attachment: pullRequest.html

Comment 48

[Diego Marcos [:dmarcos]]

Attachment: pullRequest.html

Comment 49

[David Flanagan [:djf]]

Comment on attachment 799848 [details]
pullRequest.html

Looks great. If it fixes the bug on Unagi, I'm sure it fixes it on Leo, too. This seems like a pretty clear-cut OOM.  Let's just land it.

Comment 50

[Diego Marcos [:dmarcos]]

Landed on master:

https://github.com/mozilla-b2g/gaia/commit/0cf6bd098ca5b83e148f9e1423b663c94f1501e1

Comment 51

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted 0cf6bd098ca5b83e148f9e1423b663c94f1501e1 to:
v1-train: 6324c3b047aabee83ec7419803224e8edf07db7c

Comment 52

[Tim Guan-tin Chien [:timdream] (please needinfo)]

v1.1.0hd: 6324c3b047aabee83ec7419803224e8edf07db7c