1062262 - [B2G2.0]EMAIL application closes during attaching the image from Gallery

Status: RESOLVED DUPLICATE of bug 1063658

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[Sridhar A]

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.94 Safari/537.36

Steps to reproduce:

PreCondition: Gallery app should be closed.

1) Open Email application and configure 
2) Select Compose
3) Select attachment button
4) Choose Gallery 
5) Select a photo taken with the camera.







Actual results:

Email Application is getting closed 

Reproducing rate:100%


Expected results:

Image should be attached and shown as an attachment in the Email composer.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

The most likely cause of the problem is the email app getting OOM-killed, although that really should not happen since we intentionally do chunked encoding of the attachment.

Please indicate:
- The type of the account in use
- The type of device in use (codenames are fine), including available memory
- The size of the image you are attempting to attach
- A logcat being logged before you start the attaching progress.

See https://wiki.mozilla.org/Gaia/Email/RequiredBugInfo for information on how to gather some of this information, especially the logcat.

Comment 2

[Sridhar A]

Type of account used : Gmail

Type of device in use: Nexus4

System memory info: 
Total    1870.8 MB
SwapTotal    0.0 MB
Used - cache  187.1 MB
B2G procs (PSS) 150.7 MB
Non-B2G procs 36.4 MB
Free + cache   1683.6 MB
Free          1371.6 MB
Cache        312.1 MB

Size of images used:
1) name : 19700102_034807.jpg
   size : 2.98 MB
   Orientation : 90 deg.
2) name : 19700102_034923.jpg
   size : 2.98 MB
   Orientation : 180 deg.
3) name : 19700102_034851.jpg
   size : 2.97 MB
   Orientation : 0 deg.

Observations: Images with 0 deg. orientation taken by phone camera were attached successfully.
For other orientations(90,180,270) images, it fails. Please refer to logs for the above used images.

Comment 3

[Sridhar A]

Attachment: Email_Close_logs.txt

Comment 4

[Sridhar A]

Attachment: 19700102_034807.jpg

Comment 5

[Sridhar A]

Attachment: 19700102_034923.jpg

Comment 6

[Sridhar A]

Attachment: 19700102_034851.jpg

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

Okay, so this is definitely not an OOM error.  This looks like a serious problem related to us trying to read the contents of the Blob.  Either there's been a regression in the Blob subsystem or there's some type of coordination race with the DeviceStorage-backed Blob.  Since you are mentioning other angles, I'm inclined to suspect that the camera app might be rewriting the file on disk in a way that breaks our use of Blobs.

We'll look into this more; I'll ping a camera person on IRC too.

Comment 8

[Andrew Sutherland [:asuth] (he/him)]

I talked with :djf on IRC.  Rotations happen in-memory when needed due to EXIF stuff.  As such, this is probably a memory-backed Blob thing.  Such a problem was fixed on v2.0 when it was trunk a while ago in bug 982779.

Please provide the exact gecko hash/build you are using (see the "Build identifier" section of https://wiki.mozilla.org/Gaia/Email/RequiredBugInfo); it's possible your build is out-of-date.  If your 2.0 build is recent, it would also be great if you could try and upgrade to a v2.1 Firefox OS build and attempt to duplicate there.

Comment 9

[David Flanagan [:djf]]

The attached images are not from the FirefoxOS camera. There may still be a bug here, but step 5 of the STR indicates that a user could experience this bug with photos taken on a FirefoxOS device, and that does not appear to be the case.

The photos here are 12mp and rely on EXIF orientation for correct rotation. Currently the Tarako is the only device we support that uses EXIF orientation, and it limits pictures to 2 or 3mp.

Comment 10

[Sridhar A]

This bug now I have verified in the latest build, it is reproducible with the attached images in Nexus4 device.

Below are the details:
OS Version: 2.2.0.0
Git Commit Info: 2014-09-05 05:59:58 
                 526e3ec0

In Nexus4 device, the camera resolution is limited to 5 MP. The picture sizes are varying from
500kb ~ 1MB are getting attached in Email successfully irrespective of EXIF orientation.

The attached images were taken by an Android Phone camera which supports 13 MP resolution and image sizes were about 2 MB to 4 MB. When I pushed these images to Nexus4 and try to attach in Email, it is failing for the images having EXIF orientation other than 0 deg.

One more observation is that, when Gallery app is in background, all these images were getting attached in Email successfully irrespective of EXIF orientation.

Comment 11

[David Flanagan [:djf]]

Andrew: if you change your mind about comment #7 and decide this is actually an OOM, I can investigate whether we are downsampling the 12mp source image before rotating it. If not, then there are probably some tweaks we should make to the build-time config stuff.

Sridhar (or Andrew): does this bug occur when you use the share activity from the gallery as well?  In gallery, if you select two of these big photos, can you share them with the email app? (I don't know if the email app supports more than one selected item). In the case where you select two or more photos and do a share, we do not attempt to decode and rotate the photos, so if it works in that case, then that is extra confirmation that this is related (by memory usage or memory-backed blob usage) to the rotation.

Comment 12

[Andrew Sutherland [:asuth] (he/him)]

I just reproduced on a v2.1 flame (1GB) using the 90 degree image.  While the rotation process was fairly slow, it completed successfully.  The email app dies or has its attaching process hang probabilistically, but we are definitely talking memory-backed Blob problems.  I'll file another DOM bug and have it block this one.

Comment 13

[Sridhar A]

Hi Andrew, Is there any update or plan to fix this issue as I am thinking if I can find a temporary work around to fix the issue in application side and later wait for the 1063658 to be fixed in 2.1 or 2.2 version.

Please let me know your opinion.

Comment 14

[Andrew Sutherland [:asuth] (he/him)]

Thanks for the ping; I needinfo'd the relevant parties on the platform bug 1063658.  I've currently requested v2.1 since I can't quite make a case for v2.0 right now, but it's conceivable the results of a fix would be upliftable.

Based on my reproductions on that bug, there is no email-only mitigation possible (or your-app-only mitigation).  The gallery app or camera app or whatever is calling cropResizeRotate (it's in shared/js/media/crop_resize_rotate.js at least in v2.0) needs to either cause the rotation step to be bypassed (possibly via an argument to the 'pick' WebActivity) or to use round-robin temporary files backed by DeviceStorage like the camera workaround in v1.3t for freshly taken pictures.

Note that partners may be able to make a better case for addressing bug 1063658 in v2.0 than I am and it would be fine for them to directly request blocking 2.0 on the bug, or to contact their TAM and have them help figure out how to triage things, etc.

Comment 15

[Julien Wajsberg [:julienw]]

Attachment: smaller image demonstrating the issue

Comment 16

[Andrew Sutherland [:asuth] (he/him)]

The gallery workaround in bug 1063658 has landed on v2.0, v2.1, and v2.2/trunk now which should resolve manifestations of the bug/STRs here, so I'm going to dupe this across to that bug.  Note that the fix won't show up in 2.0/2.1 builds until tomorrow.