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

RESOLVED WORKSFORME

Status

()

defect
--
major
RESOLVED WORKSFORME
4 years ago
4 years ago

People

(Reporter: jihao, Unassigned)

Tracking

({regression})

unspecified
ARM
Gonk (Firefox OS)
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.2+, b2g-v2.0 unaffected, b2g-v2.1 unaffected, b2g-v2.2 affected, b2g-master affected)

Details

(Whiteboard: [gfx-noted])

Attachments

(4 attachments)

(Reporter)

Description

4 years ago
[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
(Reporter)

Comment 1

4 years ago
Posted image test (1).gif
(Reporter)

Comment 2

4 years ago
Posted image test (2).gif
(Reporter)

Comment 3

4 years ago
Posted file logcat_1656.txt
Hi, Paladin,

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

Comment 5

4 years ago
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
Flags: needinfo?(jihao) → needinfo?(whsu)
(Reporter)

Updated

4 years ago
(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! :)
Flags: needinfo?(whsu)
[Blocking Requested - why for this release]:

Defect causes app crash.
blocking-b2g: --- → 2.2?

Comment 8

4 years ago
Blocking Reason: Crash on simple case of viewing gif.

David, can you take the first look.

Thanks
Hema
blocking-b2g: 2.2? → 2.2+
Flags: needinfo?(dflanagan)
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?
Flags: needinfo?(jihao)
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.
Flags: needinfo?(dflanagan) → needinfo?(milan)
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
Flags: needinfo?(jihao) → needinfo?(rnicoletti)
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
Flags: needinfo?(jihao)
Is it worth getting a regression range within 2.2 itself?
Flags: needinfo?(milan)
Component: Gaia::Gallery → ImageLib
Product: Firefox OS → Core
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.
Flags: needinfo?(rnicoletti)
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.
QA Contact: pcheng
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.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Seth, can you take a look at this please? This might have been caused by the work done on bug 1116716
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(seth)
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
Depends on: 1079627
Flags: needinfo?(seth) → needinfo?(ayang)
(Reporter)

Comment 19

4 years ago
(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.
Flags: needinfo?(jihao)
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.
Flags: needinfo?(ayang)
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.
Whiteboard: [gfx-noted]
Alfredo, bug 1079627 is on 37, which is 2.2, can you see if this still reproduces?
Flags: needinfo?(ayang)
Depends on: 1139005
No, I can't reproduce this bug on latest code.
However, I think this problem should be able to fix in bug 1139005.
Flags: needinfo?(ayang)
Close this bug due to comment 23.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.