858886 - [Gallery] [Crash] Gallery crashes when loading > 1000 pictures

Status: RESOLVED DUPLICATE of bug 854783

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

Description

[John Hammink]

Tested on Unagi nightly, mozilla RIL 4/5
Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/1d4c7fe3256e
Gaia   2f64311e0f23b85c29b20be9502cbdeaee8342ae
BuildID 20130405070205

STR:
 - open the gallery application with thousand of photos on the SD card (but not yet imported to gallery).
 - Do not scroll. Let the phone sit for a few minutes while loading pictures.  (Note:  because of 85883, a very large collection is continually loading new pictures).

Actual:
 - Images continue to "pop" into the view while the phone is idle.  Eventually Gallery app crashes.

Expected:
 - Without scrolling, images in the current view should not change.  There should be no crashiness

Comment 1

[John Hammink]

Attachment: adb logcat - crashing while loading > 1000 pictures to gallery

Comment 2

[John Hammink]

Although I've enabled crash reporting in settings - I'm unable to get a report; looking under /data/b2g/mozilla/Crash Reports/ and I do not see any "Pending" or other folders there.

Comment 3

[David Flanagan [:djf]]

Tell me about the photos you're using for this test, please. What is their resolution, and do they have an embedded EXIF preview?  If so, what is its resolution.

Because of gecko bugs, gallery really can't deal very will with large images unless they have embedded previews that are at least as big as the screen.

Currently, there is a bug fix that makes the gallery wait > 3 seconds after processing a large photo like that in order to allow gecko to free memory.  Without that wait we'd crash almost instantly.  But there is no perfect heuristic to avoid that kind of OOM.

There is a pending gecko patch that will help a lot in bug 854799. If that gets uplifted, I think we'll be able to avoid this OOM.  If not, we're probably screwed. I don't want to think about what happens if the phone rings while scanning large photos...  That will proabably cause an OOM too.

Comment 4

[Nicolas B. Pierron [:nbp]]

(In reply to David Flanagan [:djf] from comment #3)
> Tell me about the photos you're using for this test, please.

These are my personal photos, and I not frequently taking photos.  Are you in MTV.  I will not publish these pictures anywhere, sorry.

> What is their
> resolution, and do they have an embedded EXIF preview?  If so, what is its
> resolution.

I don't know.  Can "convert" apply a filter on the photos while keeping all properties which make then crashy?

> Because of gecko bugs, gallery really can't deal very will with large images
> unless they have embedded previews that are at least as big as the screen.
> 
> Currently, there is a bug fix that makes the gallery wait > 3 seconds after
> processing a large photo like that in order to allow gecko to free memory. 

1. That would explain why the gallery never finish loading anything.
2. This is a clear regression because with the same set of photos it was able to load them faster without any OOM.

> Without that wait we'd crash almost instantly.  But there is no perfect
> heuristic to avoid that kind of OOM.

The heuristic is to get an OOM and to fallback, then GC, and try again.  If it fails on retry, then OOM.

Comment 5

[Nicolas B. Pierron [:nbp]]

(In reply to Nicolas B. Pierron [:nbp] from comment #4)
> (In reply to David Flanagan [:djf] from comment #3)
> > Tell me about the photos you're using for this test, please.
> 
> These are my personal photos, and I not frequently taking photos.  Are you
> in MTV.  I will not publish these pictures anywhere, sorry.
> 
> > What is their
> > resolution, and do they have an embedded EXIF preview?  If so, what is its
> > resolution.
> 
> I don't know.  Can "convert" apply a filter on the photos while keeping all
> properties which make then crashy?

This is not the original set of photos, I tried to respect privacy for either the persons who are on these photos by applying an irreversible filter.  This might also change the size of the jpegs but keep the same dimensions, so I am not sure this set of photos will help reproduce the bugs.

https://people.mozilla.com/~npierron/private/photos.tar

Still I tried to keep the largest features of the original image such as images can be distinguished from each others (easier for testing), while being too blurry for recognizing any details.

Comment 6

[David Flanagan [:djf]]

(In reply to John Hammink from comment #2)
> Although I've enabled crash reporting in settings - I'm unable to get a
> report; looking under /data/b2g/mozilla/Crash Reports/ and I do not see any
> "Pending" or other folders there.

I think you're not getting a crash report because this is just an ordinary OOM.

Looking at Nicolas' photos, there are 5 megapixel images here with small EXIF previews, which is the OOM scenario that I've worked hard on. It used to be that the app would crash with just 3 of these.  Now it takes longer to crash.  If bug 854799 lands and is uplifted, we'll be able to fix this.

In the meantime, I'm going to resolve this bug as a duplicate of 854783.