Closed Bug 911387 Opened 7 years ago Closed 6 years ago

[Buri][Camera] Frequent "Picture not saved errors" when running nightly

Categories

(Core :: Graphics: Layers, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla28
blocking-b2g koi+
Tracking Status
firefox26 --- wontfix
firefox27 --- wontfix
firefox28 --- fixed
b2g-v1.2 --- fixed

People

(Reporter: marcia, Assigned: sotaro)

References

Details

(Keywords: regression, Whiteboard: [fromAutomation][xfail])

Attachments

(3 files, 1 obsolete file)

Seen while running Buri on the latest nightly

STR:
1) Launch Build ID: 20130830040204
2) Launch Camera App
3) Take a vertical picture with the camera
4) Take a horizontal picture with the camera
5) Receive the attached error

Build ID: 20130830040204
Gecko: http://hg.mozilla.org/mozilla-central/rev/c7459bc8e449
Gaia: 407fbfb6a9de68ec4db2f0f3dc6c67463e293f47
Platform Version: 26.0a1
Attached file cameralogcat.txt
I am not seeing this using today's 2013-09-03-04-02-04 buri build, so resolving this as WFM. Will reopen if it seen again.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
I did see this again when testing yesterday's Buri build, but I could not reproduce it reliably. Seems to happen when I pressed the camera button in rapid fire succession.
blocking-b2g: koi? → ---
From the logcat in comment 1, all I see out of place is:

I/Gecko   (  505): setBufferCount: client owns some buffers
E/SurfaceTextureClient(  144): ISurfaceTexture::setBufferCount(7) returned Invalid argument
E/QCameraHWI_Preview(  144): set_buffer_count failed: Invalid argument (22)
E/QCameraHWI_Preview(  144): virtual android::status_t android::QCameraStream_preview::initDisplayBuffers(): cannot get memory from surface texture client, ret = -2147483648
E/QCameraHWI(  144): android::status_t android::QCameraHardwareInterface::startPreview2(): X error - can't start stream!

But I'm not sure this is related to the error screenshot in comment 0.
(In reply to Marcia Knous [:marcia] from comment #3)
> I did see this again when testing yesterday's Buri build, but I could not
> reproduce it reliably. Seems to happen when I pressed the camera button in
> rapid fire succession.

I agree with this. We are seeing it reliably and repeatedly in the test automation that takes 3 photos in a row. The test does go very quickly too.
Reopening for more investigation.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I can replicate this manually by just doing what the automated test does.

you need to do it quickly, with left hand on the thumbnail and right hand on the bottom toolbar (or the opposite if you're left handed!)

STR:
1. Load camera
2. Tap capture photo button
3. Tap the thumbnail (at top of camera app)
4. Tap camera app in the bottom menu bar
5. Tap the capture photo button again
Repeat this 2-3 times quickly and you will surely see the error.

Device Hamachi
Gecko  http://hg.mozilla.org/mozilla-central/rev/aa986b6ce882
Gaia  959ac2f692d85072ffdc3d16a041b5bf4735ae59
BuildID 20131010040202
Version 27.0a1
Couple of questions:

1. Does this reproduce on 1.1?
2. Can we try getting a regression window again?

If it does not reproduce on 1.1, this should be nomed for koi.
Blocks: 801898
Whiteboard: [fromAutomation]
Blocks: 925851
No longer blocks: 801898
Whiteboard: [fromAutomation] → [fromAutomation][xfail]
Sotaro - See the below IRC chat - we're thinking this might be a gfx regression instead of a camera regression. What do you think? Do you think this gfx related?

12:06 PM <jsmith> mikeh: Any chance you could help out with looking into bug 911387? We've currently turned off the associated camera automated test on device, but I'd like to get that test turned back on. I have a contractor looking into identifying when it regressed as well.
12:09 PM <mikeh> jsmith: that log is full of errors.
12:09 PM <mikeh> jsmith: looks like the camera couldn't start the preview stream--out of memory.
12:11 PM <mikeh> jsmith: "cannot get memory from surface texture client" / "startPreview2(): X error - can't start stream!"
12:11 PM <jsmith> mikeh: Hmm...so is that gfx related potentially, less so of the actual camera code?
12:11 PM → ahubenya joined (ahubenya@moz-BB506F61.hsd1.wa.comcast.net)
12:11 PM <mikeh> jsmith: it looks like--I'd get sotaro's opinion on this one.
12:12 PM <jsmith> mikeh: Okay. I'll needinfo sotaro on the bug.
Flags: needinfo?(sotaro.ikeda.g)
I think it is not camera related. The codes around camera is basically same. Within other codes, gfx is most possible.
Flags: needinfo?(sotaro.ikeda.g)
Bt STR in  Comment 7, I can reproduce the problem. I got following log. It seem like genlock problem.

> E libgenlock: perform_lock_unlock_operation: GENLOCK_IOC_DREADLOCK failed (lockType0x0, err=Invalid argument fd=60)
> E QCameraHWI_Preview: putBufferToSurface: genlock_unlock_buffer failed, handle =0x10ba450
blocking-b2g: --- → koi?
Component: Gaia::Camera → Graphics: Layers
Product: Boot2Gecko → Core
> 1. Does this reproduce on 1.1?
> 2. Can we try getting a regression window again?
> 
> If it does not reproduce on 1.1, this should be nomed for koi.

From the symptom, it seems like the problem happens since b2gv1.2.
Blocks: GFXB2G1.2
Assignee: nobody → sotaro.ikeda.g
At this stage, I would rather not fix this for 1.2 - it is not really a common user behavior - but we should consider it for 1.3.
blocking-b2g: koi? → 1.3?
(In reply to Milan Sreckovic [:milan] from comment #13)
> At this stage, I would rather not fix this for 1.2 - it is not really a
> common user behavior - but we should consider it for 1.3.

Disagree - we do not tolerate introducing major regressions into FxOS releases. We would have to permanently xfail the test on 1.2, which I don't think is acceptable. We can only not block on regressions that are minor. This isn't minor.
blocking-b2g: 1.3? → koi?
QA Contact: gbennett
QA Contact: gbennett → ktucker
This issue does not reproduce on 07/13 Buri v 1.2.0 Mozilla RIL

Environmental Variables
Device: Buri 1.2.0 Mozilla RIL
Build ID: 20130713050718
Gecko: http://hg.mozilla.org/mozilla-central/rev/32c3ccd8946c
Gaia: fd4a4675ec44ab459b49b17606557024b09dbefe
Platform Version: 25.0a1

No error saving pictures when following the original steps and the steps from comment 7.


This issue reproduces on the 07/14 Buri v 1.2.0 Mozilla RIL

Environmental Variables
Device: Buri v 1.2.0 Mozilla RIL
Build ID: 20130714030201
Gecko: http://hg.mozilla.org/mozilla-central/rev/18467a85acf6
Gaia: 6724eb7733dd425b65027d0c2fd414bc9b74d624
Platform Version: 25.0a1

The save error message is shown when following the steps in comment 7.


I could not reproduce this issue on Leo v 1.1.0 COM RIL

Environmental Variables
Device: Leo v 1.1.0 COM RIL
Build ID: 20131001041206
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/c630289d6388
Gaia: 02b975e6ce12922928c74276ac7d19432a03f126
Platform Version: 18.1
RIL Version: 01.01.00.019.240 

Pictures are saved without error following the original steps and the steps from comment 7.
QA Contact: ktucker → gbennett
QA Contact: gbennett → ktucker
Something changed in today's build?
This is passing now!

Device Hamachi
Gecko  http://hg.mozilla.org/mozilla-central/rev/182b8450e32f
Gaia  d544afff519a4930dec372c6406b365d27bb9cba
BuildID 20131020040204
Version 27.0a1
To clarify: sometimes passing but still getting a failure. I wouldn't mark this resolved yet without further clarification.
Regression + bad UX hence a koi+
blocking-b2g: koi? → koi+
(In reply to Preeti Raghunath(:Preeti) from comment #18)
> Regression + bad UX hence a koi+

Bad UX because of "I pressed the camera button in rapid fire succession"?
Assignee: sotaro.ikeda.g → nobody
(In reply to Milan Sreckovic [:milan] from comment #19)
> (In reply to Preeti Raghunath(:Preeti) from comment #18)
> > Regression + bad UX hence a koi+
> 
> Bad UX because of "I pressed the camera button in rapid fire succession"?

It's a regression & it's blocking a test that's running fine for multiple months. Our operators we work with are not tolerant of regressions unless they are non-noticable, so we can't tolerate a simple multiple picture test like this. It won't survive a certification process.
Not arguing koi+, just was wondering about "bad UX" comment.
Assignee: nobody → sotaro.ikeda.g
From the debugging, the source cause of the problem is genlock failure. That causes the incomplete preview stop procedure, and then causes failure of start preview. Finally reached to failure of taking a picture.
The patch add handling LayerManagerComposite::ClearCachedResources() called case because of application go to background.
By applying the patch, I did not sees a problem in Comment 7 on master hamachi.
Attachment #826951 - Flags: review?(nical.bugzilla)
Comment on attachment 826951 [details] [diff] [review]
patch - Add calling CompositableBackendSpecificData::ClearData() in Detach()

Review of attachment 826951 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/layers/composite/CompositableHost.h
@@ +265,5 @@
>    {
> +    if (mBackendData) {
> +      mBackendData->ClearData();
> +    }
> +

It would be more correct to place this inside the if block below.
Attachment #826951 - Flags: review?(nical.bugzilla) → review-
update the place to call ClearData().
Attachment #826951 - Attachment is obsolete: true
Attachment #827387 - Flags: review?(nical.bugzilla)
Comment on attachment 827387 [details] [diff] [review]
patch v2 - Add calling CompositableBackendSpecificData::ClearData() in Detach()

Review of attachment 827387 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks!
Attachment #827387 - Flags: review?(nical.bugzilla) → review+
Keywords: checkin-needed
Blocks: 935118
Blocks: 933348
https://hg.mozilla.org/mozilla-central/rev/7aad56401354
Status: REOPENED → RESOLVED
Closed: 7 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
You need to log in before you can comment on or make changes to this bug.