945774 - Messages app is closing while resizing an image for MMS from the Camera

Status: RESOLVED DUPLICATE of bug 941160

(Core :: Graphics, defect)

Description

[Zac C (:zac)]

STR:

1. Load messages app
2. Input a recipient
3. Input a message body
4. Tap attachment icon
5. Select 'camera'
6. Take a photo
7. Tap select to choose it
8. A few seconds after returning to the SMS app it will close. There is no crash report.

Perhaps OOM killer?

Build:
Device Hamachi
Base     V1.2_US_20131115.cfg
Gecko  http://hg.mozilla.org/mozilla-central/rev/8648aa476eef
Gaia  31808a29cfcffa584b6a88b4f1e515387f485a1b
BuildID 20131203040236
Version 28.0a1


The first failing build was this one:
https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2g_ril/hamachi-eng-mozilla-central-20131202092621-ril01.02.00.019.102.zip

Comment 1

[Zac C (:zac)]

Capturing a logcat for this now.

Comment 2

[Zac C (:zac)]

Attachment: logcat for test run

Comment 3

[Natalya Kot [:nkot]]

have encountered this issue while running manual smoketest today as well 

Buri 1.3 m-c
BuildID: 20131203040236
Gaia: 31808a29cfcffa584b6a88b4f1e515387f485a1b
Gecko: 8648aa476eef
Version: 28.0a1
Firmware: v1.2_20131115

Comment 4

[Jason Smith [:jsmith]]

Can someone add the changesets for the regression window here?

Also - Can someone get a dmesg log?

Comment 5

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #4)
> Can someone add the changesets for the regression window here?
> 
> Also - Can someone get a dmesg log?

Also - can someone double check this isn't reproducing on 1.2?

Comment 6

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #5)
> (In reply to Jason Smith [:jsmith] from comment #4)
> > Can someone add the changesets for the regression window here?
> > 
> > Also - Can someone get a dmesg log?
> 
> Also - can someone double check this isn't reproducing on 1.2?

A manual confirmation of the regression window would be helpful as well.

Comment 7

[Sarah Parsons]

This does appear to be an OOM issue, but the first failing build in comment 0 is incorrect because I was able to get this issue to repro on Buri 1.2.  Also, I was not able to repro on 1.1.

Adding regression-window wanted and will add the appropriate changesets in a bit. 

See dmesg log below:

<4>[  293.934113] send sigkill to 763 ((Preallocated a), adj 10, size 5591
<4>[  294.695099] select 717 (Camera), adj 10, size 9941, to kill
<4>[  294.695114] send sigkill to 717 (Camera), adj 10, size 9941
<4>[  294.919746] mm-qcamera-daem used greatest stack depth: 4640 bytes left
<1>[  294.994529] #########ffff##########
<4>[  294.994556] s5k5ca_sensor_power_down IN
<6>[  295.140361] [adsp.c:msm_adsp_disable] disable 'QCAMTASK'
<6>[  295.141711] [adsp.c:msm_adsp_disable] disable 'VFETASK'
<6>[  295.143078] [adsp.c:msm_adsp_put] closing module QCAMTASK
<6>[  295.143106] [adsp.c:msm_adsp_put] closing module VFETASK
<3>[  295.143141] msm_sensor_power: sensor already in power down state
<4>[  295.773318] select 520 (Messages), adj 2, size 25743, to kill
<4>[  295.773333] send sigkill to 520 (Messages), adj 2, size 25743
<4>[  295.884654] Compositor invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0

Comment 8

[Sarah Parsons]

This issue started to occur on the Buri 1.2 Build ID: 20130909114657

Gaia   aa4180e9286d385fa6b62d236f30fb24cd8b93e9
SourceStamp 218d4334d29e
BuildID 20130909114657
Version 26.0a1


Last working Buri 1.2 Build ID: 20130906040204

Gaia   94e5f269874b02ac0ea796b64ab995fce9efa4b3
SourceStamp ab5f29823236
BuildID 20130906040204
Version 26.0a1

Comment 9

[Julien Wajsberg [:julienw]]

Nothing interesting in Gaia in this range.

Comment 10

[Zac C (:zac)]

(In reply to Sarah Parsons from comment #7)
> This does appear to be an OOM issue, but the first failing build in comment
> 0 is incorrect because I was able to get this issue to repro on Buri 1.2. 

I was looking at the automation history to get this regression range. This step of the test, at least, passed in previous days before I filed this.

I recall from other OOM crashes with the Camera that the content of the image matters too. A black image (as if device is just left flat on the desk) is easier to manage, easier to compress, for example.

Comment 11

[Jason Smith [:jsmith]]

Sotaro - Any thoughts on why we are OOMing here?

Comment 12

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #11)
> Sotaro - Any thoughts on why we are OOMing here?

Also - Is this potentially related to the problem seen in bug 939962?

Comment 13

[Sotaro Ikeda [:sotaro]]

I did not confirmed the bug yet. Yes, it seems similar to Bug 941160 Bug 939962.

Comment 14

[Julien Wajsberg [:julienw]]

The resizing code in SMS is at [1]. Is the algorithm too naive?

[1] https://github.com/mozilla-b2g/gaia/blob/master/apps/sms/js/utils.js#L266-L353

Comment 15

[Preeti Raghunath(:Preeti)]

Sotaro,

Are you actively working on the bug?

Is yes, please own the same.

Comment 16

[Sotaro Ikeda [:sotaro]]

I am not working for oom now. Bug 941160 Bug 939962 is assigned to SkiaGL related engineers.

Comment 17

[Jason Smith [:jsmith]]

Milan - Can you find an appropriate assignee for this bug?

Setting koi+ per Taipei triage for OOM regression.

Comment 18

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

Does the problem go away when we disable canvas acceleration with pref("gfx.canvas.azure.accelerated", false);?

Comment 19

[Jason Smith [:jsmith]]

(In reply to Milan Sreckovic [:milan] from comment #18)
> Does the problem go away when we disable canvas acceleration with
> pref("gfx.canvas.azure.accelerated", false);?

QA Wanted - Can someone see if this reproduces with this pref set to false?

Comment 20

[Dietrich Ayala (:dietrich)]

Assigning to Milan to find an owner until this is closed out.

Comment 21

[Sarah Parsons]

After adding pref("gfx.canvas.azure.accelerated", false);? to the user.js I am no longer able to repro this issue on Buri 1.2 Build ID: 20131206004002.

Gaia   d48df33cbdae2063f12b09e3dca07ff7a2f2a3cc
SourceStamp fd0302696c57
BuildID 20131206004002
Version 26.0

Comment 22

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

Right.  Likelly a duplicate of 941160.

Comment 23

[Kai-Chih Hu [:khu]]

Because 1.2 is going to be finished, should we mark this bug from koi+ to 1.3+? Thanks.

Comment 24

[Andreas Gal :gal]

If we move this to 1.3 we have to disable skiaGL on 1.2. I recently added a patch to trunk that might help. If that doesn't we need to understand what skia does here internally and how to make it not hang on to so much memory.

Comment 25

[Jason Smith [:jsmith]]

Ryan - Why is this marked fixed?

Comment 26

[Ryan VanderMeulen [:RyanVM]]

mcMerge being silly. It picked up this:
https://hg.mozilla.org/mozilla-central/rev/a59592aa8efb

Sorry.

Comment 27

[Zac C (:zac)]

oops my fault, sorry guys, I un-xfailed this because it has been passing steadily in the automation for the last week. 
Should dupe/move discussion over to bug 941160?

Comment 28

[Jason Smith [:jsmith]]

(In reply to Zac C (:zac) from comment #27)
> oops my fault, sorry guys, I un-xfailed this because it has been passing
> steadily in the automation for the last week. 
> Should dupe/move discussion over to bug 941160?

Yes. If this ends reproducing after bug 941160 gets fixed, then we'll reopen.