Bug 187834

Summary: ASSERTION FAILED: index == m_currentFrame && !m_currentFrame in WebCore::BitmapImage::imageFrameAvailableAtIndex
Product: WebKit Reporter: Ryan Haddad <ryanhaddad>
Component: ImagesAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: ap, bfulgham, eric.carlson, jer.noble, realdawei, sabouhallawa, simon.fraser, tsavell, webkit-bug-importer, zalan
Priority: P2 Keywords: InRadar
Version: Other   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Crash log none

Description Ryan Haddad 2018-07-19 17:24:25 PDT 
Created attachment 345408 [details]
Crash log

This flaky assertion failure is seen on High Sierra and Sierra Debug WK1 bots with layout test fast/images/animated-image-mp4-crash.html:

ASSERTION FAILED: index == m_currentFrame && !m_currentFrame
./platform/graphics/BitmapImage.cpp(590) : void WebCore::BitmapImage::imageFrameAvailableAtIndex(size_t)
1   0x108ef7099 WTFCrash
2   0x114edf738 WebCore::BitmapImage::imageFrameAvailableAtIndex(unsigned long)
3   0x114f7d447 WebCore::ImageSource::cacheNativeImageAtIndexAsync(WTF::RetainPtr<CGImage*>&&, unsigned long, WebCore::SubsamplingLevel, WebCore::DecodingOptions const&, WebCore::DecodingStatus)
4   0x114f892a1 WebCore::ImageSource::startAsyncDecodingQueue()::$_0::operator()() const::'lambda'()::operator()()
5   0x114f88de9 WTF::Function<void ()>::CallableWrapper<WebCore::ImageSource::startAsyncDecodingQueue()::$_0::operator()() const::'lambda'()>::call()
6   0x108f1c26b WTF::Function<void ()>::operator()() const
7   0x108f48a0b WTF::dispatchFunctionsFromMainThread()
8   0x108f4b5f5 -[JSWTFMainThreadCaller call]
9   0x7fff505bd2b5 __NSThreadPerformPerform
10  0x7fff4e489d81 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
11  0x7fff4e54165c __CFRunLoopDoSource0
12  0x7fff4e46cd30 __CFRunLoopDoSources0
13  0x7fff4e46c1ad __CFRunLoopRun
14  0x7fff4e46ba07 CFRunLoopRunSpecific
15  0x106c0235b runTest(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)
16  0x106c00621 runTestingServerLoop()
17  0x106bffade dumpRenderTree(int, char const**)
18  0x106c02d6f DumpRenderTreeMain(int, char const**)
19  0x106c8b342 main
20  0x7fff76810015 start
21  0x2

https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=fast%2Fimages%2Fanimated-image-mp4-crash.html
Comment 1 Ryan Haddad 2018-07-19 17:26:30 PDT 
This test was added with https://trac.webkit.org/changeset/231920
Comment 2 Radar WebKit Bug Importer 2018-07-20 19:28:54 PDT 
<rdar://problem/42454633>
Comment 3 Said Abou-Hallawa 2018-07-23 12:18:47 PDT 
I think there is a bug here.

For animated images, the expectation is the frames are decoded in order. No frames will be skipped even if decoding the current frame takes more than its duration period. This is because the frames of an animated images are just deltas of changes applied to the first frame. The animated image decoder has to decode frame(n - 1) to be able to decode frame(n). This may lead the image decoder to decode all the frames from 0 till n to be able to provide frame(n).

For video images, the situation is different. If the network is slow or decoding the frames takes long time, it is oaky to drop some frames to achieve the goal which is: playing the video in a certain period of time.