The assert is that the reference count of an object being-deleted changed from zero to non-zero. wild guess: some other thread has a pointer to the object, but was not really an owner (in the sense that it ref'd the object ahead of time).
This can happen (again, just a swag) as follows:
Thread 1:
a = new object;
pass_a_to_another_thread(a);
a->unref();
Thread 2:
a = receiver_object();
a->ref();
The flaw is that it is too late for thread 2 to "ref" the pointer, since it may race with the sender unrefing it.
Just a guess though.
Handing this to Khushal, as this looks to have started near-ish the time after the penultimate reland of shader / paintrecord stuff landed, and has a GetSkShader -> Playback bit in the callstack, which was added in https://chromium-review.googlesource.com/c/chromium/src/+/690734.
The change was landed again finally on https://chromium-review.googlesource.com/c/chromium/src/+/695449 starting from this build: https://luci-milo.appspot.com/buildbot/chromium.gpu/Linux%20Release%20%28NVIDIA%29/112249.
The failures on the LinuxRelease bot did start after that. I tried getting a local repro but no luck so far. This change shouldn't affect the threading behaviour with how the shaders are used. We create a PaintShader on the worker thread during playback now, which internally holds a reference to the SkShader, but the usage of this shader is restricted to the playback step on that worker thread.
Thanks khushalsagar@ for pointing that out. Please link this (Blocking/Blocked on) to the other bugs as appropriate. Since this is affecting the linux_chromium_rel_ng tryserver the appropriate thing to do would be to revert again.
There is one change that was introduced here. Earlier we would have definitely created the |cached_shader_|, which is the SkImageShader, inside a PaintShader at record time on the main thread. Because prior to this change, we were transforming it to an SkShader to query whether it is an image backed shader in HasDiscardableImagesFromFlags:
SkShader* shader = flags.getSkShader();
SkImage* image = shader ? shader->isAImage(nullptr, nullptr) : nullptr;
return image && image->isLazyGenerated();
Now that code uses the shader type on PaintShader directly:
if (!flags.HasShader())
return false;
else if (flags.getShader()->shader_type() == PaintShader::Type::kImage)
return flags.getShader()->paint_image().IsLazyGenerated();
else if (flags.getShader()->shader_type() == PaintShader::Type::kPaintRecord)
return flags.getShader()->paint_record()->HasDiscardableImages();
So its possible to have 2 worker threads racing to create the |cached_shader_|...
This crash has high impact on Chrome's stability.
Signature: SkPaintPriv::ShouldDither.
Channel: canary. Platform: win.
Labeling issue 771156 with ReleaseBlock-Dev.
If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.
- Go/Fracas
Comment 1 by kbr@chromium.org
, Oct 3 2017Components: Internals>Compositing>Rasterization Blink>Paint
Labels: -Type-Bug Type-Bug-Regression
Owner: enne@chromium.org