Bug 187834 - ASSERTION FAILED: index == m_currentFrame && !m_currentFrame in WebCore::BitmapImage::imageFrameAvailableAtIndex
Summary: ASSERTION FAILED: index == m_currentFrame && !m_currentFrame in WebCore::Bitm...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Images (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-07-19 17:24 PDT by Ryan Haddad
Modified: 2018-07-23 12:19 PDT (History)
10 users (show)

See Also:


Attachments
Crash log (103.37 KB, text/plain)
2018-07-19 17:24 PDT, Ryan Haddad
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
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.