1121899 - [Flame][Gallery]when you view a gif picture and then slide screen,Gallery crash happened.

Status: RESOLVED WORKSFORME

(Core :: Graphics: ImageLib, defect)

Description

[Paladin]

Attachment: 2015-01-15-16-56-46.png

[1.Description]:
[Flame][v2.2][Gallery]when you view a gif picture and then slide screen,Gallery crash happened.

Found time:16:56
Attachment:2015-01-15-16-56-46.png &logcat_1656.txt and test(1).gif & test(2).gif

The detail infomation:
-Title:
B2G 37.0a2 Crash Report [@ JS_updateMallocCounter(JSContext*, unsigned int) ]
B2G 37.0a2 Crash Report [@ mozilla::CDMCaps::Lock() ]

-Crash Report:
https://crash-stats.mozilla.com/report/index/981be8cb-79ef-4f04-b44d-bc9b22150115
https://crash-stats.mozilla.com/report/index/8fcb242c-5261-4e7a-ad21-d5c742150115

[2.Testing Steps]: 
1.Open Gallery.
2.Tap a gif picture.
3.Slide screen to switch picture.



[3.Expected Result]: 
3. There shouldn't be any problem when you switch pictures.

[4.Actual Result]: 
3. A "Gallery" crash report pops up.

[5.Reproduction build]: 
Gaia-Rev        7c5b27cad370db377b18a742d3f3fdb0070e899f
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/748b20315f75
Build-ID        20150114002502
Version         37.0a2
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150114.040029
FW-Date         Wed Jan 14 04:00:40 EST 2015
Bootloader      L1TC000118D0

[6.Reproduction Frequency]: 
Once,3/10

[7.TCID]: 
Free Test

Comment 1

[Paladin]

Attachment: test (1).gif

Comment 2

[Paladin]

Attachment: test (2).gif

Comment 3

[Paladin]

Attachment: logcat_1656.txt

Comment 4

[William Hsu [:whsu]]

Hi, Paladin,

May I have your help?
Does it happen on the other branches (v2.1 & v2.0)?
Thanks.

Comment 5

[Paladin]

Hi William,
We can't reproduce this issue on latest Flame 2.0/2.1
Reproducing rate: 0/5

Device info:
Flame 2.0 build:
Gaia-Rev        736933b25ded904f0cb935a0d48f1f3cf91d33ad
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/8ff0d933175c
Build-ID        20150115000203
Version         32.0
--------------------------------
Flame 2.1 build:
Gaia-Rev        8d4846d7bec777046dc5e3d2b8005adb1370f1f7
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/8eb9bc3a945a
Build-ID        20150115001207
Version         34.0

Comment 6

[William Hsu [:whsu]]

(In reply to Paladin from comment #5)
> Hi William,
> We can't reproduce this issue on latest Flame 2.0/2.1
> Reproducing rate: 0/5
> 
> Device info:
> Flame 2.0 build:
> Gaia-Rev        736933b25ded904f0cb935a0d48f1f3cf91d33ad
> Gecko-Rev      
> https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/8ff0d933175c
> Build-ID        20150115000203
> Version         32.0
> --------------------------------
> Flame 2.1 build:
> Gaia-Rev        8d4846d7bec777046dc5e3d2b8005adb1370f1f7
> Gecko-Rev      
> https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/8eb9bc3a945a
> Build-ID        20150115001207
> Version         34.0

Thanks Paladin!
Have a nice weekend! :)

Comment 7

[William Hsu [:whsu]]

[Blocking Requested - why for this release]:

Defect causes app crash.

Comment 8

[Hema Koka [:hema]]

Blocking Reason: Crash on simple case of viewing gif.

David, can you take the first look.

Thanks
Hema

Comment 9

[Russ Nicoletti [:russn]]

I took a look and was not able to reproduce the crash using the buildID specified (20150114002502) nor am I able to reproduce using the latest master (buildID 20150121010204). I copied the two gifs three times each so that I have 6 gifs on the device. I swiped back and forth dozens and dozens of times without a crash.

FWIW, based on the two crash reports, the crash is happening libxul, although it seems the two crashes are not in the same part of libxul.

Paladin, can you provide more details regarding your testing? How many pictures on the device? How many gifs? Does the crash happen when swiping from a gif to a non-gif, gif to gif, non-gif to gif?

Comment 10

[David Flanagan [:djf]]

I can reproduce this on a Flame with a master nightly from last week.  Given that these are actual crashes, they must be coming from Gecko, not Gaia, so I'll be passing this bug on to Milan's team.

First, some observations:

1) The images that cause the crash are animated gifs and they are both over 1mb in file size, so this is probably quite a stress test for our devices.

2) This may be memory-related. If I change my flame from 319mb of memory to 1024 then I no longer see the crashes.

3) In 1.3T and 1.4, Gallery has special case code to reject gifs that have a reasonable image size but a large file size, assuming that those images were animated gifs that would cause OOM errors when displayed. That code never landed on master. If we need a workaround, we could easily use that code to prevent Gallery from even attempting to display large animated gifs like these.  There is a real bug here, however, and it would be better to just fix this in Gecko.

4) I've seen various symptoms when I follow the STR in for this bug:

a) A crash that displays the crash reporter dialog like the one attached. I've seen this once or twice right after scanning the new animated gifs when I first tap on the thumbnail. I've gotten a crash just going directly to the image without any swiping at all.

b) A crash that just displays a notification without the crash reporter. These might have been OOMs.

c) Twice when I swipe from an animated gif back to a previous still photo sometimes the photo did not decode and I saw a blank screen and this error in the logcat: JavaScript Error: "Image corrupt or truncated: blob:app://gallery.gaiamobile.org/502b9c21-f93f-4e66-9f63-532c070ae861#-moz-samplesize=3"

d) Once, when I swiped to an animated gif, it was frozen and the rest of the UX was, too. I could not swipe to other images, and none of the on-screen Gallery app buttons worked either. All I could do was use the home button to return to the homescreen.

5) If I tap directly on the thumbnail for one of these animated gifs it displays and animates correctly. If instead I tap on a photo before or after it and then swipe to the animated gif, it will usually animate one cycle and then freeze.

Milan: is there someone on your team who could investigate this? The crash reports in comment #0 seem particularly relevant but I don't know what to do with them. Comment #5 seems to indidcate that this is a regression in 2.2 and if so, I imagine we need to get it fixed in Gecko. If that comment is wrong and this is not a regression but just a not-enough-memory issue, then I can work around in gaia by forbidding large gifs, but I'll need advice from someone on your team about what limit to set.

Comment 11

[David Flanagan [:djf]]

Clearing the needinfo for Paladin, since I was able to reproduce easily. 
Russ: how much RAM is your phone configured at? I was not able to reproduce when running with 1024mb.

% adb reboot bootloader
% fastboot getvar mem
% fastboot reboot

Comment 12

[David Flanagan [:djf]]

Paladin,

We need to figure out whether this bug is memory-related and whether it really is a new regression in 2.2.  You have tested it in 2.2, 2,1 and 2.0. Please let us know how much memory each of those devices was configured for when you tested.  If this really does not reproduce on a 319mb Flame in 2.1, then please set the regression keyword

Comment 13

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

Is it worth getting a regression range within 2.2 itself?

Comment 14

[Russ Nicoletti [:russn]]

My flame was configured for 1024mb. When I configure it for 319mb, I can easily reproduce. So the evidence suggests the problem is memory related.

Comment 15

[Pi Wei Cheng [:piwei] (inactive)]

Confirmed that 3.0 is affected and 2.1 is unaffected. On 3.0 it reproduces about 1 out of 4 attempts of swiping to next picture (or just staying on Gallery seems to crash the app). For 2.1 it doesn't happen after 20 attempts.

Tested with Flame 319MB memory.

Working on getting the window now.

Comment 16

[Pi Wei Cheng [:piwei] (inactive)]

mozilla-inbound regression window:

Last Working Environmental Variables:
Device: Flame
BuildID: 20150107013601
Gaia: 69ac77cfa938fae2763ac426a80ca6e5feb6ad25
Gecko: 07c75e0d6f67
Version: 37.0a1 (2.2 Master)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

First Broken Environmental Variables:
Device: Flame
BuildID: 20150107014057
Gaia: 69ac77cfa938fae2763ac426a80ca6e5feb6ad25
Gecko: 6e4dce410c27
Version: 37.0a1 (2.2 Master)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Gaia is the same so it's a Gecko issue.

Gecko pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=07c75e0d6f67&tochange=6e4dce410c27

Possibly caused by patches to bug 1116716.

Comment 17

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

Seth, can you take a look at this please? This might have been caused by the work done on bug 1116716

Comment 18

[Seth Fowler [:seth] [:s2h]]

Examining the first crash stack, it looks like this should be fixed by bug 1079627, which I am planning to uplift to B2G 2.2 ASAP.

I have no idea what's going on in the second crash stack. Honestly that looks like a totally different bug to me.

Alfredo, needinfo'ing you because you most recently touched the line of code where we crash in the second crash stack. Any idea what's happening? For reference, the line of code is:

http://hg.mozilla.org/releases/mozilla-b2g37_v2_2/annotate/748b20315f75/dom/base/ImageEncoder.cpp#l96

And the crash report is:

https://crash-stats.mozilla.com/report/index/981be8cb-79ef-4f04-b44d-bc9b22150115

Comment 19

[Paladin]

(In reply to David Flanagan [:djf] from comment #12)
> Paladin,
> 
> We need to figure out whether this bug is memory-related and whether it
> really is a new regression in 2.2.  You have tested it in 2.2, 2,1 and 2.0.
> Please let us know how much memory each of those devices was configured for
> when you tested.  If this really does not reproduce on a 319mb Flame in 2.1,
> then please set the regression keyword

We tested it in Flame 2.0,2.1,2.2 and all Flame were configured for 319 Mb.

Comment 20

[Alfredo Yang (:alfredo)]

The crash is at:

http://hg.mozilla.org/releases/mozilla-b2g37_v2_2/file/4a90da67661e/dom/html/HTMLCanvasElement.cpp#l565

It looks like jsapi.cx() returning an invalid pointer? I'll try to reproduce it in my local build.

Comment 21

[Alfredo Yang (:alfredo)]

I've tried to reproduced it locally several days but it always crashed on RasterImage stuff. And the crash doesn't happen on m-c.

Since this bug crashed at http://hg.mozilla.org/releases/mozilla-b2g37_v2_2/file/5d56316cad1f/js/src/jsapi.cpp#l1459. It probably cx->zone() or cx->runtime() is invalid under low memory condition. But I can't prove it.

I'll try to reproduce it again once bug 1079627 is uplift to 2.2.

Comment 22

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

Alfredo, bug 1079627 is on 37, which is 2.2, can you see if this still reproduces?

Comment 23

[Alfredo Yang (:alfredo)]

No, I can't reproduce this bug on latest code.
However, I think this problem should be able to fix in bug 1139005.

Comment 24

[Kai-Chih Hu [:khu]]

Close this bug due to comment 23.