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

RESOLVED FIXED in Firefox 32, Firefox OS v2.0

Status

Firefox OS
Gaia::Camera
--
critical
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: Greg Grisco, Assigned: aosmond)

Tracking

({crash})

unspecified
2.0 S6 (18july)
ARM
Gonk (Firefox OS)
crash
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)

(Reporter)

Description

4 years ago
Created attachment 8452040 [details]
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).
(Reporter)

Updated

4 years ago
Blocks: 1011657
Whiteboard: [CR 689938]
(Reporter)

Comment 1

4 years ago
Created attachment 8452043 [details]
EXTRA file attachment (with logs)

Updated

4 years ago
Component: General → Gaia::Camera
Keywords: crash
Whiteboard: [CR 689938] → [CR 689938][b2g-crash]
What device? What build?
Flags: needinfo?(ggrisco)

Updated

4 years ago
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
(Reporter)

Comment 4

4 years ago
(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)

Comment 7

4 years ago
(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
(Assignee)

Comment 8

4 years ago
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.
Attachment #8452564 - Flags: feedback?(ggrisco)
(Assignee)

Comment 9

4 years ago
Created attachment 8453053 [details] [diff] [review]
bug1035531.patch, v1.1

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+

Updated

4 years ago
blocking-b2g: 2.0? → 2.0+
(Reporter)

Comment 11

4 years ago
(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.
(Assignee)

Updated

4 years ago
Status: NEW → ASSIGNED
status-b2g-v1.4: --- → affected
status-b2g-v2.0: --- → affected
status-b2g-v2.1: --- → affected
Keywords: checkin-needed
(Reporter)

Comment 12

4 years ago
We haven't seen this crash since applying the patch, thanks.
https://hg.mozilla.org/mozilla-central/rev/904c9b948214
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
https://hg.mozilla.org/releases/mozilla-aurora/rev/e52bc38eac66
status-b2g-v2.0: affected → fixed
status-b2g-v2.1: affected → fixed
status-firefox31: --- → wontfix
status-firefox32: --- → fixed
status-firefox33: --- → fixed
Target Milestone: --- → 2.0 S6 (18july)

Updated

4 years ago
Whiteboard: [caf priority: p1][CR 689938][b2g-crash] → [caf-crash 133][caf priority: p1][CR 689938][b2g-crash]

Comment 16

4 years ago
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.