Closed Bug 1035531 Opened 10 years ago Closed 10 years ago

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

Categories

(Firefox OS Graveyard :: Gaia::Camera, defect)

ARM
Gonk (Firefox OS)
defect
Not set
critical

Tracking

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

RESOLVED FIXED
2.0 S6 (18july)
blocking-b2g 2.0+
Tracking Status
firefox31 --- wontfix
firefox32 --- fixed
firefox33 --- fixed
b2g-v1.4 --- affected
b2g-v2.0 --- fixed
b2g-v2.1 --- fixed

People

(Reporter: ggrisco, Assigned: aosmond)

References

Details

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

Crash Data

Attachments

(3 files, 1 obsolete file)

Attached 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
Attached 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: 10 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.

Attachment

General

Creator:
Created:
Updated:
Size: