skia /
skia /
04a6578d2bc7f0434eed0326c3cf17bdf80065e7 [graphite] Track whether or not the Resource is reusable on the Resource
If a Shareable resource enters the return queue with a usage ref, but
then has a second usage ref added before the return queue is processed
(possible because it's shareable so remains in fResourceMap), AND
that second usage ref is removed on another thread between when the
cache thread has removed the return queue but hasn't processed the
resources in it, we can end up in a situation where the shareable
resource has a LastRemovedRef::kUsage event processed twice.
On the first process, it appears as shareable and has no usage refs
(because the other thread simultaneously dropped its usage ref and
re-added it to the new return queue). This allows the resource to be
reset to a non-shareable scratch resoure. It is not re-added to
the resource map at this point because we know it already is in it.
However, on the second return queue event, the resource now appears as
a non-shareable resource that dropped its last usage ref and we think
we should add the resource back to the reusable map. Since it wasn't
actually removed from the map, we have duplicate entries holding the
same pointer.
Eventually when the resource is purged, only one entry will be
removed from the map. Subsequent interaction with the map has the
chance to read from the second entry's now-dangling pointer.
This pulls a small part of https://skia-review.googlesource.com/c/skia/+/888809
into a separate CL to always track whether or not the Resource is
stored in fResourceMap so we can correctly make the second return
queue event a no-op.
Bug: b/388762255
Bug: b/331589189
Change-Id: Icc037fe9d3c62e2f34d0e709fc10259a12a4a92c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/937039
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Greg Daniel <egdaniel@google.com>
3 files changed
