922734 - [B2G][Contacts][Gallery] Trying to add a gallery picture to a contact force closes gallery

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect, P2)

Description

[gbennett]

Attachment: ContactsGalleryForceCloseLOG.txt

Description:
When adding a gallery photo to a contact the gallery app force closes. It usually closes after selecting a photo and in the cropping section. No crash dump is shown on the device.

Repro Steps:
1) Updated Buri 1.3 mozRIL to Build ID: 20131001040206
2) Open contacts > create a new contact
3) Click on Add Picture > Gallery
4) Select a photo and wait a bit

Actual:
Gallery abruptly closes.

Expected:
Photo is chosen for cropping and if chosen appears properly within the chosen contact.

Environmental Variables
Device: Buri 1.3 mozRIL
Build ID: 20131001040206
Gecko: http://hg.mozilla.org/mozilla-central/rev/d71579c316c1
Gaia: 67243760c86561e365bdd6def519105366e24be3
Platform Version: 27.0a1
Firmware Version: 20130912

Notes: Adding a photo through Camera functions properly.
Repro frequency: 100%, 8/8
See attached: ContactsGalleryForceCloseLOG.txt

Comment 1

[Jason Smith [:jsmith]]

Seeing a lot of this in the logcat.

10-01 10:19:58.800: E/msm7627a.gralloc(140): gralloc failed err=Out of memory
10-01 10:19:58.800: W/GraphicBufferAllocator(140): alloc(292, 390, 1, 00000300, ...) failed -12 (Out of memory)
10-01 10:19:59.010: I/Gecko(1191): OpenGL version detected: 200
10-01 10:19:59.010: I/Gecko(1191): SharedSurface_Gralloc::Create -------
10-01 10:19:59.010: E/memalloc(140): /dev/pmem: No more pmem available
10-01 10:19:59.010: E/msm7627a.gralloc(140): gralloc failed err=Out of memory
10-01 10:19:59.010: W/GraphicBufferAllocator(140): alloc(320, 410, 1, 00000300, ...) failed -12 (Out of memory)
10-01 10:19:59.070: I/Gecko(1191): SharedSurface_Gralloc::Create -------
10-01 10:19:59.070: E/memalloc(140): /dev/pmem: No more pmem available
10-01 10:19:59.070: E/msm7627a.gralloc(140): gralloc failed err=Out of memory
10-01 10:19:59.070: W/GraphicBufferAllocator(140): alloc(300, 390, 1, 00000300, ...) failed -12 (Out of memory)

Comment 2

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

Eventually, we run out of memory.  Sometimes it's just pmem and there is a fallback that we're working on, but eventually, we run out of system memory as well.  We won't know what this case does until we test with the fallback.

Comment 3

[gbennett]

Removing regression-windowwanted as this did not repro in yesterday's smoke pass.

Comment 4

[Jason Smith [:jsmith]]

(In reply to gbennett from comment #3)
> Removing regression-windowwanted as this did not repro in yesterday's smoke
> pass.

We need changesets then of yesterday's build and today's build in order to confirm a regression window.

Comment 5

[Mila Davydova]

I am only seeing this issue to occur when selecting a large image from the gallery (size of which is > 100MB). 
The rest of the images chosen from the gallery get opened in a Crop view and user is able to add a selected image to the contact.  
According to gbennett this issue first occurred on 10/01 1.3 Buri Build, but I am also seeing it to happen on Buri v1.2 build.

Build ID: 20131002004001
Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/b955a00f4167
Gaia: def8e152db6a317162c03a316f68c409f3af3979
Platform Version: 26.0a2

Comment 6

[Mila Davydova]

Correction to the comment 5

The gallery closes when user selects an image that's larger than 1MB.

Comment 7

[Sotaro Ikeda [:sotaro]]

gbennett, can you also get dmesg log by "adb shell dmesg"?

Comment 8

[Sotaro Ikeda [:sotaro]]

(In reply to Mila Davydova from comment #6)
> Correction to the comment 5
> 
> The gallery closes when user selects an image that's larger than 1MB.

When I tried same thing locally. I got the following log by dmesg command. From it, at first low memory killer kills other app and at last out of memory killer kills Gallery.

<4>[  695.340814] select 718 ((Preallocated a), adj 10, size 4734, to kill
<4>[  695.340829] send sigkill to 718 ((Preallocated a), adj 10, size 4734
<4>[  696.235756] select 381 (Homescreen), adj 8, size 5672, to kill
<4>[  696.235774] send sigkill to 381 (Homescreen), adj 8, size 5672
<4>[  696.484414] b2g invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
<4>[  696.484468] [<c00497f4>] (unwind_backtrace+0x0/0x12c) from [<c01355c8>] (dump_header.clone.1+0x6c/0x18c)
<4>[  696.484493] [<c01355c8>] (dump_header.clone.1+0x6c/0x18c) from [<c0135728>] (oom_kill_process.clone.0+0x40/0x21c)
<4>[  696.484514] [<c0135728>] (oom_kill_process.clone.0+0x40/0x21c) from [<c0135b5c>] (out_of_memory+0x258/0x320)
<4>[  696.484539] [<c0135b5c>] (out_of_memory+0x258/0x320) from [<c013957c>] (__alloc_pages_nodemask+0x4fc/0x6ac)
<4>[  696.484561] [<c013957c>] (__alloc_pages_nodemask+0x4fc/0x6ac) from [<c013360c>] (filemap_fault+0x2e8/0x3e8)
<4>[  696.484583] [<c013360c>] (filemap_fault+0x2e8/0x3e8) from [<c014d044>] (__do_fault+0x50/0x45c)
<4>[  696.484604] [<c014d044>] (__do_fault+0x50/0x45c) from [<c014d9c4>] (handle_pte_fault+0x32c/0xbe8)
<4>[  696.484624] [<c014d9c4>] (handle_pte_fault+0x32c/0xbe8) from [<c014e8a0>] (handle_mm_fault+0x1c0/0x1dc)
<4>[  696.484649] [<c014e8a0>] (handle_mm_fault+0x1c0/0x1dc) from [<c05b3c50>] (do_page_fault+0x164/0x314)
<4>[  696.484678] [<c05b3c50>] (do_page_fault+0x164/0x314) from [<c003d1ac>] (do_PrefetchAbort+0x34/0x94)
<4>[  696.484701] [<c003d1ac>] (do_PrefetchAbort+0x34/0x94) from [<c05b20a0>] (ret_from_exception+0x0/0x10)
<4>[  696.484714] Exception stack(0xcaf89fb0 to 0xcaf89ff8)
<4>[  696.484728] 9fa0:                                     4439e910 4361018c 00000109 466e5044
<4>[  696.484746] 9fc0: 4361018c 466e5000 4439e910 0000000c 00000001 bef89484 0000029e bef89630
<4>[  696.484761] 9fe0: 00000000 bef89440 41c23a39 41c0bcb4 00000030 ffffffff
<4>[  696.484771] Mem-info:
<4>[  696.484778] Normal per-cpu:
<4>[  696.484786] CPU    0: hi:   90, btch:  15 usd:   0
<4>[  696.484806] active_anon:40472 inactive_anon:4 isolated_anon:0
<4>[  696.484811]  active_file:352 inactive_file:358 isolated_file:64
<4>[  696.484818]  unevictable:169 dirty:0 writeback:0 unstable:0
<4>[  696.484823]  free:445 slab_reclaimable:542 slab_unreclaimable:1348
<4>[  696.484828]  mapped:550 shmem:12 pagetables:455 bounce:0
<4>[  696.484858] Normal free:1780kB min:1772kB low:2212kB high:2656kB active_anon:161888kB inactive_anon:16kB active_file:1408kB inactive_file:1432kB unevictable:676kB isolated(anon):0kB isolated(file):256kB present:196912kB mlocked:0kB dirty:0kB writeback:0kB mapped:2200kB shmem:48kB slab_reclaimable:2168kB slab_unreclaimable:5392kB kernel_stack:1848kB pagetables:1820kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:9510 all_unreclaimable? yes
<4>[  696.484886] lowmem_reserve[]: 0 0 0
<4>[  696.484898] Normal: 16*4kB 1*8kB 1*16kB 1*32kB 4*64kB 3*128kB 0*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 1784kB
<4>[  696.484933] 962 total pagecache pages
<4>[  696.487379] 55808 pages of RAM
<4>[  696.487386] 771 free pages
<4>[  696.487393] 9617 reserved pages
<4>[  696.487398] 1277 slab pages
<4>[  696.487404] 2609 pages shared
<4>[  696.487409] 0 pages swap cached
<6>[  696.487418] [ pid ]   uid  tgid total_vm      rss cpu oom_adj oom_score_adj name
<6>[  696.487458] [   98]     0    98       78        1   0     -16          -941 ueventd
<6>[  696.487476] [  111]     0   111      864       43   0     -16          -941 adbd
<6>[  696.487491] [  112]     0   112      108       63   0     -16          -941 init
<6>[  696.487508] [  139]  1000   139      213       32   0     -16          -941 servicemanager
<6>[  696.487524] [  140]     0   140     1009       46   0     -16          -941 vold
<6>[  696.487539] [  143]     0   143      833       67   0     -16          -941 fakeperm
<6>[  696.487554] [  144]     0   144    41498    13076   0       0             0 b2g
<6>[  696.487571] [  145]  1001   145      210       28   0     -16          -941 rilproxy
<6>[  696.487586] [  146]     0   146     1862       55   0     -16          -941 netd
<6>[  696.487603] [  147]     0   147      180       24   0     -16          -941 debuggerd
<6>[  696.487618] [  148]  1001   148     5088      363   0     -16          -941 rild
<6>[  696.487634] [  149]  1019   149     3022      218   0     -16          -941 drmserver
<6>[  696.487649] [  150]  1013   150     4547      313   0     -16          -941 mediaserver
<6>[  696.487666] [  151]  1002   151      338       31   0     -16          -941 dbus-daemon
<6>[  696.487681] [  152]     0   152      214       31   0     -16          -941 installd
<6>[  696.487698] [  153]  1017   153      437       47   0     -16          -941 keystore
<6>[  696.487713] [  155]     0   155      108       67   0     -16          -941 init
<6>[  696.487729] [  168]  1000   168      764       94   0     -16          -941 mm-qcamera-daem
<6>[  696.487746] [  192]  1001   192     1508       87   0     -16          -941 qmuxd
<6>[  696.487761] [  198]  2000   198      198       47   0     -16          -941 sh
<6>[  696.487776] [  199]  1001   199     1549       79   0     -16          -941 netmgrd
<6>[  696.487794] [  368]  1007   368      176       28   0     -16          -941 logwrapper
<6>[  696.487809] [  369]  1010   369      667       99   0     -16          -941 wpa_supplicant
<6>[  696.487826] [  533]  1014   533      235       24   0     -16          -941 dhcpcd
<6>[  696.487844] [  650] 10650   650    50034    17219   0       2           134 Gallery
<6>[  696.487859] [  696] 10696   696    25452     4930   0       2           134 Communications
<3>[  696.487873] Out of memory: Kill process 650 (Gallery) score 509 or sacrifice child
<3>[  696.487891] Killed process 650 (Gallery) total-vm:200136kB, anon-rss:67636kB, file-rss:1240kB

Comment 9

[gbennett]

Attachment: adbshelldmesg_bug922734

Here is the adb shell dmesg for today's 1.2 aurora mozRIL build right as I repro'd the issue using Mila's specific photo that seems to have the easiest repro (it's a large img). Would you also like the shell dmesg for 1.3?

Comment 10

[Sotaro Ikeda [:sotaro]]

(In reply to gbennett from comment #9)
> Here is the adb shell dmesg for today's 1.2 aurora mozRIL build right as I
> repro'd the issue using Mila's specific photo that seems to have the easiest
> repro (it's a large img).

Thanks. v1.2 is enough for now.

Comment 11

[Sotaro Ikeda [:sotaro]]

From the following in attachment 813339 [details], Gallery was also killed because of out of memory.

<4>[ 1822.356413] Gallery: page allocation failure: order:0, mode:0xd2
<4>[ 1822.356519] [<c00497f4>] (unwind_backtrace+0x0/0x12c) from [<c0138fbc>] (warn_alloc_failed+0xe4/0x108)
<4>[ 1822.356579] [<c0138fbc>] (warn_alloc_failed+0xe4/0x108) from [<c013964c>] (__alloc_pages_nodemask+0x5cc/0x6ac)
<4>[ 1822.356639] [<c013964c>] (__alloc_pages_nodemask+0x5cc/0x6ac) from [<c02e02d8>] (_kgsl_sharedmem_page_alloc+0xec/0x330)
<4>[ 1822.356703] [<c02e02d8>] (_kgsl_sharedmem_page_alloc+0xec/0x330) from [<c02da740>] (kgsl_ioctl_gpumem_alloc+0xa0/0x190)
<4>[ 1822.356759] [<c02da740>] (kgsl_ioctl_gpumem_alloc+0xa0/0x190) from [<c02db448>] (kgsl_ioctl+0x1dc/0x2ac)
<4>[ 1822.356813] [<c02db448>] (kgsl_ioctl+0x1dc/0x2ac) from [<c0175924>] (do_vfs_ioctl+0x500/0x57c)
<4>[ 1822.356859] [<c0175924>] (do_vfs_ioctl+0x500/0x57c) from [<c01759d4>] (sys_ioctl+0x34/0x54)
<4>[ 1822.356904] [<c01759d4>] (sys_ioctl+0x34/0x54) from [<c0042d60>] (ret_fast_syscall+0x0/0x30)
<4>[ 1822.356931] Mem-info:
<4>[ 1822.356948] Normal per-cpu:
<4>[ 1822.356968] CPU    0: hi:   90, btch:  15 usd:  85
<4>[ 1822.357011] active_anon:36434 inactive_anon:3 isolated_anon:0
<4>[ 1822.357024]  active_file:0 inactive_file:7 isolated_file:0
<4>[ 1822.357036]  unevictable:169 dirty:0 writeback:0 unstable:0
<4>[ 1822.357048]  free:1 slab_reclaimable:547 slab_unreclaimable:1327
<4>[ 1822.357059]  mapped:279 shmem:12 pagetables:472 bounce:0
<4>[ 1822.357126] Normal free:4kB min:1772kB low:2212kB high:2656kB active_anon:145736kB inactive_anon:12kB active_file:0kB inactive_file:28kB unevictable:676kB isolated(anon):0kB isolated(file):0kB present:196912kB mlocked:0kB dirty:0kB writeback:0kB mapped:1116kB shmem:48kB slab_reclaimable:2188kB slab_unreclaimable:5308kB kernel_stack:2000kB pagetables:1888kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:1327 all_unreclaimable? yes
<4>[ 1822.357196] lowmem_reserve[]: 0 0 0
<4>[ 1822.357231] Normal: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
<4>[ 1822.357326] 190 total pagecache pages
<4>[ 1822.362911] 55808 pages of RAM
<4>[ 1822.362933] 440 free pages
<4>[ 1822.362948] 9617 reserved pages
<4>[ 1822.362963] 1251 slab pages
<4>[ 1822.362978] 514 pages shared
<4>[ 1822.362993] 0 pages swap cached
<4>[ 1857.228011] select 2093 ((Preallocated a), adj 10, size 5670, to kill
<4>[ 1857.228033] send sigkill to 2093 ((Preallocated a), adj 10, size 5670
<4>[ 1857.680911] select 1673 (Communications), adj 2, size 4680, to kill
<4>[ 1857.680933] select 1986 (Gallery), adj 2, size 16942, to kill
<4>[ 1857.680944] send sigkill to 1986 (Gallery), adj 2, size 16942

Comment 12

[Jason Smith [:jsmith]]

Removing smoketest keyword - comment 6 indicates this is only happening with images greater than 1 MB, which does not make this a smoketest blocker.

Comment 13

[gbennett]

Attachment: Contacts_AddPictureGalleryForceCloseLOG.txt

(In reply to Jason Smith [:jsmith] from comment #12)
> Removing smoketest keyword - comment 6 indicates this is only happening with
> images greater than 1 MB, which does not make this a smoketest blocker.

I was able to repro this issue on:

Device: Buri 1.3 mozRIL
Gaia: 122ff8c6363227501f4121e5a3892ba41d4c0417
SourceStamp: 64b497e6f593
BuildID: 20131008064334
Version: 27.0a1

with any picture selected regardless of size at the end of todays smoketest. The attached log shows gallery force closing for three different images recorded in the following order: 1. A picture taken with my HTC Rezound, 1.18MB 3264x1840res 2. An image from the internet transfered via bluetooth to my phone, 196.3kb 1600x1600 3. An image taken with my Buri, 48.4kb 480x640

I agree that it shouldn't block smoketest as it's not consistant enough possibly due to us flashing/reseting/restarting the phone so often for testing, but I do believe this will easily happen in the wild as most people keep their phone on for more than a week without shutdown/restart.

Comment 14

[Mila Davydova]

While looking for the regression window, I was able to see another symptom of this issue to occur. When the user has a lot of large pictures (more then 1 MB) in the gallery and attempts to add a picture to the contact, pictures don't finish loading to the device and gallery app force closes. 

Regression range:

Buri 1.2 Build ID: 20130912040201 - Does not reproduce
Gecko: http://hg.mozilla.org/mozilla-central/rev/a98569f21abe
Gaia: 9ffd2899eb91388f7fc1ce6f7a895a6f5f922c05
Platform Version: 26.0a1

Buri 1.2 Build ID: 20130913040201 - Reproduces
Gecko: http://hg.mozilla.org/mozilla-central/rev/b9029b1de410
Gaia: 8ccb741b6adcfe9a78b842c17e5874242c0f8b86
Platform Version: 26.0a1

Comment 15

[Jason Smith [:jsmith]]

Confirmed to affect 1.2 - moving to koi?

Comment 16

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

David, Sotaro, if we're "just" running out of memory, is this a good case for handling OOM on Gaia side as was discussed?

Comment 17

[David Flanagan [:djf]]

(In reply to Milan Sreckovic [:milan] from comment #16)
> David, Sotaro, if we're "just" running out of memory, is this a good case
> for handling OOM on Gaia side as was discussed?

Maybe. I'm not sure how I'd handle the OOM in Gaia, but at least it would be handleable.

If I could pick one gecko bug that would make Gallery better, it would probably be bug 854795. If someone could pick that bug up again, it would make a huge difference.

Comment 14 seems to imply that this bug manifests itself when the gallery app is busy scanning other photos.  

Gallery is designed to work well with images from the camera, because the camera includes EXIF previews that are big enough to fill the phone screen.

Testers always seem to load of their memory cards with unrealistically large photos that do not have EXIF previews. This makes the scanning process slower and much more memory intensive because each large image must be decoded and a preview created for it.  If the gallery app is busy doing that, there isn't much system memory left for it to do other things like crop images.

See bug 925666 which seems quite similar to this one.

It would be helpful if QA people would refer to images by their resolution rather than their file size. I want to know megapixels, not megabytes of file.  For each megapixel of image, we require 4 megabytes of memory.

We used to have resolution limits on the images that gallery would accept to prevent OOMs like this. I'm not sure if we have lifted them and are now getting lots of OOM bugs, or if something else has changed.

Comment 18

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

We have the bug 854795 that David mentions and would relieve some of the memory pressure, but couldn't be considered for 1.2.  Then there is bug 925666 which has been mentioned as similar, is fixed on master, and sitting as leo?  Can somebody try master to see if this problem is still around?

Comment 19

[Mike Lee [:mlee]]

Waiting on QA feedback for this before setting an assignee.

- FxOS Perf Triage

Comment 20

[Natalya Kot [:nkot]]

I worked with reporter on this bug, none of us were able to reproduce it on today's m-c Buri build

I tried to to open images in single view while the gallery is still scanning as bug 925666 suggested and tried both camera taken and external images - NO repros

Buri m-c
BuildID: 20131104044747
Gaia: 1aee772a384f1ed1148f08c6c7df45d2fe35506e
Gecko: b4143e04bea1
Version: 28.0a1
Firmware: 20131015

Comment 21

[Mike Lee [:mlee]]

QA, please retest this against 1.2. m-c is 1.3 and we need this fixed for 1.2.

Thanks,
FxOS Perf Triage

Comment 22

[Natalya Kot [:nkot]]

not happening on 1.2 either, seeing bug 921205 a lot but not this issue

Buri BuildID: 20131106004004
Gaia: 2140c987fdde1c99097018f7e93b0bbd43d2125d
Gecko: 6a831fcb96f4
Version: 26.0
Firmware: 20131015