[Webkit-unassigned] [Bug 169576] Follow-up (r213833): write a layout test for 169199

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=169576

--- Comment #3 from Said Abou-Hallawa <sabouhallawa at apple.com> ---
(In reply to comment #2)
> I'm working on this.
> 
> I have the test that deletes the decoder and works fine. But without r213833
> it doesn't necessarily cause a crash, as it's a race condition.
> 
> With the implementation of BitmapImage::clearDecoder() you suggest,
> ImageSource::clear() calls setData() just after setting the ImageFrameCache
> decoder to nullptr, and that setData() creates a new decoder that the
> decoding thread will use without crashing.
> 
> The crash happens only when the decoding thread is using the decoder exactly
> between its destruction and the creation of the new one, which is pretty
> hard to reproduce. I could force it though, using an implementation of
> BitmapImage::clearDecoder() that just deletes the decoder and doesn't cause
> setData() to be called.
> 
> Should I do that? Or should I use the implementation you suggest, even if
> the crash is not easily reproducible without r213833?

I think you are right. You can instead add a setting flag which clears the decoder immediately  after requesting a new frame in BitmapImage::internalStartAnimation(). You can do something similar to Internals::setImageFrameDecodingDuration().

You can also try run-webkit-tests with --repeat-each=100 for example. This might cause the crash to happen with scenarios like this.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170314/e17c0dec/attachment-0001.html>