Closed
Bug 1035531
Opened 11 years ago
Closed 11 years ago
Failed CHECK in GonkCameraSource::dataCallbackTimestamp() while stability testing
Categories
(Firefox OS Graveyard :: Gaia::Camera, defect)
Tracking
(blocking-b2g:2.0+, 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)
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•11 years ago
|
Blocks: CAF-v2.0-FC-metabug
Whiteboard: [CR 689938]
Reporter | ||
Comment 1•11 years ago
|
||
Updated•11 years ago
|
Updated•11 years ago
|
Whiteboard: [CR 689938][b2g-crash] → [caf priority: p1][CR 689938][b2g-crash]
Comment 3•11 years ago
|
||
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•11 years ago
|
||
(In reply to Diego Marcos [:dmarcos] from comment #2)
> What device? What build?
Answered by cafbot in Comment 3.
Flags: needinfo?(ggrisco)
Comment 5•11 years ago
|
||
Sorry but I don't know what an msm8610 is. What's the code name?
Flags: needinfo?(b2guser)
Comment 6•11 years ago
|
||
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•11 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•11 years ago
|
||
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•11 years ago
|
||
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 10•11 years ago
|
||
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•11 years ago
|
blocking-b2g: 2.0? → 2.0+
Reporter | ||
Comment 11•11 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•11 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•11 years ago
|
||
We haven't seen this crash since applying the patch, thanks.
Comment 13•11 years ago
|
||
Keywords: checkin-needed
Comment 14•11 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 15•11 years ago
|
||
status-firefox31:
--- → wontfix
status-firefox32:
--- → fixed
status-firefox33:
--- → fixed
Target Milestone: --- → 2.0 S6 (18july)
Updated•11 years ago
|
Whiteboard: [caf priority: p1][CR 689938][b2g-crash] → [caf-crash 133][caf priority: p1][CR 689938][b2g-crash]
Comment 16•10 years ago
|
||
No STR is present to create test case to address bug.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(rmitchell)
Updated•10 years ago
|
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.
Description
•