Failed CHECK in GonkCameraSource::dataCallbackTimestamp() while stability testing

RESOLVED FIXED in Firefox 32

Status

defect
--
critical
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: ggrisco, Assigned: aosmond)

Tracking

({crash})

unspecified
2.0 S6 (18july)
ARM
Gonk (Firefox OS)
Dependency tree / graph
Bug Flags:
in-moztrap -

Firefox Tracking Flags

(blocking-b2g:2.0+, firefox31 wontfix, firefox32 fixed, firefox33 fixed, b2g-v1.4 affected, b2g-v2.0 fixed, b2g-v2.1 fixed)

Details

(Whiteboard: [caf-crash 133][caf priority: p1][CR 689938][b2g-crash], crash signature)

Attachments

(3 attachments, 1 obsolete attachment)

Posted file decoded minidump
STR are unclear at this point, but we found a this crash during stability test which seems to come from a failed CHECK in GonkCameraSource.

Uploading minidump and EXTRA files (with logs).
Whiteboard: [CR 689938]
Component: General → Gaia::Camera
Keywords: crash
Whiteboard: [CR 689938] → [CR 689938][b2g-crash]
What device? What build?
Flags: needinfo?(ggrisco)
Whiteboard: [CR 689938][b2g-crash] → [caf priority: p1][CR 689938][b2g-crash]
Observed on: 

Device: msm8610
Gonk Version: AU_LINUX_GECKO_B2G_KK_3.6.01.04.00.000.023
Moz BuildID: 20140630000201
B2G Version: 2.0
Gecko Version: 32.0a2
Gaia:  http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=c0c8ad187c0466285f2580531e09f8322996f561
Gecko: http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=ef0781044f85ee7f364236c074ab0b7644c38ff8
(In reply to Diego Marcos [:dmarcos] from comment #2)
> What device? What build?

Answered by cafbot in Comment 3.
Flags: needinfo?(ggrisco)
Sorry but I don't know what an msm8610 is. What's the code name?
Flags: needinfo?(b2guser)
It's a QRD, but this bug appears on other platforms: see bug 1018129.

Andrew and I discussed this in IRC and we think the solution is to remove the CHECK() that's causing the abort and just discard frames with suspicious timestamps.
Flags: needinfo?(b2guser)
(In reply to Mike Habicher [:mikeh] from comment #6)
> It's a QRD, but this bug appears on other platforms: see bug 1018129.
> 
> Andrew and I discussed this in IRC and we think the solution is to remove
> the CHECK() that's causing the abort and just discard frames with suspicious
> timestamps.

Thanks Mike. 

Assigning this to Andrew who is investigating.
Assignee: nobody → aosmond
Posted patch bug1035531.patch, v1 (obsolete) — Splinter Review
Resolve the issue by dropping frames with a bad timestamp while logging an error instead of asserting. Greg, can you give it a whirl to see if you can reproduce when it would have asserted and check if the resulting video is acceptable (i.e. frames do not keep dropping)? I have yet to see this issue in my own testing.
Attachment #8452564 - Flags: feedback?(ggrisco)
Fix nits that are bound to be brought up in review :). Cancelling feedback after re-reading the description; I doubt we will be able to reproduce this in a satisfactory timeframe. It is best to get the crash resolved in the field and keep an eye out for the new error log in the future for situations where the final recording quality suffers.

try: https://tbpl.mozilla.org/?tree=Try&rev=b763366f1805
Attachment #8452564 - Attachment is obsolete: true
Attachment #8452564 - Flags: feedback?(ggrisco)
Attachment #8453053 - Flags: review?(mhabicher)
Comment on attachment 8453053 [details] [diff] [review]
bug1035531.patch, v1.1

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

Thanks for taking care of this, Andrew.

I'd really like to see some feedback from CAF on it.
Attachment #8453053 - Flags: review?(mhabicher) → review+
blocking-b2g: 2.0? → 2.0+
(In reply to Andrew Osmond [:aosmond] from comment #8)
> Created attachment 8452564 [details] [diff] [review]
> bug1035531.patch, v1
> 
> Resolve the issue by dropping frames with a bad timestamp while logging an
> error instead of asserting. Greg, can you give it a whirl to see if you can
> reproduce when it would have asserted and check if the resulting video is
> acceptable (i.e. frames do not keep dropping)? I have yet to see this issue
> in my own testing.

Ok, we'll give it a try, thanks.
Status: NEW → ASSIGNED
Keywords: checkin-needed
We haven't seen this crash since applying the patch, thanks.
https://hg.mozilla.org/mozilla-central/rev/904c9b948214
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Whiteboard: [caf priority: p1][CR 689938][b2g-crash] → [caf-crash 133][caf priority: p1][CR 689938][b2g-crash]
No STR is present to create test case to address bug.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(rmitchell)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(rmitchell)
Flags: in-moztrap-
You need to log in before you can comment on or make changes to this bug.