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
Capturing a logcat for this now.
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
Can someone add the changesets for the regression window here? Also - Can someone get a dmesg log?
blocking-b2g: --- → 1.3?
Keywords: qawanted, regression
(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?
(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.
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
Keywords: qawanted → regressionwindow-wanted
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
Nothing interesting in Gaia in this range.
(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.
Sotaro - Any thoughts on why we are OOMing here?
blocking-b2g: 1.3? → koi?
Component: Gaia::SMS → Gaia::Camera
(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?
I did not confirmed the bug yet. Yes, it seems similar to Bug 941160 Bug 939962.
Component: General → Graphics
Product: Firefox OS → Core
The resizing code in SMS is at . Is the algorithm too naive?  https://github.com/mozilla-b2g/gaia/blob/master/apps/sms/js/utils.js#L266-L353
Sotaro, Are you actively working on the bug? Is yes, please own the same.
I am not working for oom now. Bug 941160 Bug 939962 is assigned to SkiaGL related engineers.
Milan - Can you find an appropriate assignee for this bug? Setting koi+ per Taipei triage for OOM regression.
blocking-b2g: koi? → koi+
Does the problem go away when we disable canvas acceleration with pref("gfx.canvas.azure.accelerated", false);?
(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?
Assigning to Milan to find an owner until this is closed out.
Assignee: nobody → milan
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
Right. Likelly a duplicate of 941160.
Assignee: milan → snorp
Because 1.2 is going to be finished, should we mark this bug from koi+ to 1.3+? Thanks.
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.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
Whiteboard: [fromAutomation][xfail] → [fromAutomation]
Ryan - Why is this marked fixed?
mcMerge being silly. It picked up this: https://hg.mozilla.org/mozilla-central/rev/a59592aa8efb Sorry.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla29 → ---
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?
(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.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago → 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 941160
You need to log in before you can comment on or make changes to this bug.