Closed
Bug 1291163
Opened 8 years ago
Closed 8 years ago
Intermittent dom/canvas/test/webgl-mochitest/test_capture.html | application crashed [@ mozilla::layers::PersistentBufferProviderShared::BorrowDrawTarget(mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const &)]
Categories
(Core :: Graphics: CanvasWebGL, defect)
Core
Graphics: CanvasWebGL
Tracking
()
RESOLVED
FIXED
mozilla51
People
(Reporter: intermittent-bug-filer, Assigned: nical)
References
Details
(Keywords: intermittent-failure, Whiteboard: [gfx-noted])
Attachments
(1 file)
(deleted),
patch
|
sotaro
:
review+
ritu
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
Comment 1•8 years ago
|
||
Nical,
Here is an assert at:
https://hg.mozilla.org/mozilla-central/annotate/ffac2798999c5b84f1b4605a1280994bb665a406/gfx/layers/PersistentBufferProvider.cpp#l196
Flags: needinfo?(nical.bugzilla)
Whiteboard: [gfx-noted]
Assignee | ||
Comment 2•8 years ago
|
||
orangefactor shows 3 instances of this intermittent failure, all of which happening just after a device reset.
This is when trying to get a texture for the canvas to draw into, and we already have buffered 4 textures which are marked as busy (the compositor hasn't released them). In theory we throttle the main thread so that this never happens, but I can imagine that the device reset puts us in buggy situation where we didn't unlock the textures on the compositor side.
Assignee: nobody → nical.bugzilla
Flags: needinfo?(nical.bugzilla)
Assignee | ||
Comment 3•8 years ago
|
||
This should do. If after this the intermittent persists, we can turn the MOZ_ASSERT(false) into a non-fatal gfxCriticalNote, but I'd rather keep crashing debug builds when something like that happens if possible.
Attachment #8777767 -
Flags: review?(sotaro.ikeda.g)
Updated•8 years ago
|
Attachment #8777767 -
Flags: review?(sotaro.ikeda.g) → review+
Comment hidden (Intermittent Failures Robot) |
Pushed by nsilva@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/9beaa7589405
Make sure TextureHosts are read-unlock'ed if Compositor::EndFrame is not called. r=sotaro
Comment 6•8 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox51:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
Comment 7•8 years ago
|
||
Should we consider landing this on Aurora as well?
status-firefox50:
--- → affected
Flags: needinfo?(nical.bugzilla)
Assignee | ||
Comment 8•8 years ago
|
||
Comment on attachment 8777767 [details] [diff] [review]
ReadUnlock if we are not going to call EndFrame
Approval Request Comment
[Feature/regressing bug #]:
[User impact if declined]: Some crashes related to device resets.
[Describe test coverage new/current, TreeHerder]: None.
[Risks and why]: low risk, this patch is simple and assumes the worst cases so it tends to be more robust than before patch.
[String/UUID change made/needed]: None.
Flags: needinfo?(nical.bugzilla)
Attachment #8777767 -
Flags: approval-mozilla-aurora?
Comment on attachment 8777767 [details] [diff] [review]
ReadUnlock if we are not going to call EndFrame
Fixes an intermittent failure, Aurora50+
Attachment #8777767 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 10•8 years ago
|
||
bugherder uplift |
You need to log in
before you can comment on or make changes to this bug.
Description
•