Stack-overflow in blink::BitmapImage::StartAnimationInternal |
||||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=4582647451090944 Fuzzer: noel-image-flip Job Type: linux_asan_chrome_v8_arm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0xff52bf9c Crash State: blink::BitmapImage::StartAnimationInternal Sanitizer: address (ASAN) Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_v8_arm&range=505841:505937 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4582647451090944 Issue filed automatically. See https://github.com/google/clusterfuzz-tools for more information.
,
Oct 3 2017
Automatically applying components based on crash stacktrace and information from OWNERS files. If this is incorrect, please apply the Test-Predator-Wrong-Components label.
,
Oct 3 2017
Test Predator has given the following results: images: UMA number of frames dropped for animated images. by khushalsagar@chromium.org Changelist touched lines near the crashed line in frame #10 blink::BitmapImage::StartAnimationInternal(double) (distance = 0 lines away) Changed files BitmapImage.cpp, BitmapImage.h, BitmapImageTest.cpp, with the same CrashedDirectory(third_party/WebKit/Source/platform/graphics) as BitmapImage.cpp (in frame#10, frame#11, frame#12, frame#13, frame#14, frame#15, frame#16) Touched files in stacktrace - BitmapImage.cpp Changed files BitmapImage.cpp, BitmapImage.h, BitmapImageTest.cpp, with the same CrashedComponent(Blink>Paint) as BitmapImage.cpp (in frame#10, frame#11, frame#12, frame#13, frame#14, frame#15, frame#16) @khushalsagar -- Could you please look into this issue, kindly reassign if it has nothing to do with your changes. Thank You.
,
Oct 7 2017
ClusterFuzz has detected this issue as fixed in range 506957:506969. Detailed report: https://clusterfuzz.com/testcase?key=4582647451090944 Fuzzer: noel-image-flip Job Type: linux_asan_chrome_v8_arm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0xff52bf9c Crash State: blink::BitmapImage::StartAnimationInternal Sanitizer: address (ASAN) Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_v8_arm&range=505841:505937 Fixed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_v8_arm&range=506957:506969 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4582647451090944 See https://github.com/google/clusterfuzz-tools for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page.
,
Oct 7 2017
ClusterFuzz testcase 4582647451090944 is verified as fixed, so closing issue as verified. If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.
,
Oct 8 2017
The bug was marked fixed because of https://chromium.googlesource.com/chromium/src/+/051a012c57a3fdfd6c933ec3df1c0e60d247a73a which disables image animations in blink so we don't hit the code path in the bug. The root cause is still there.
,
Oct 9 2017
Issue 772869 has been merged into this issue.
,
Oct 9 2017
Users experienced this crash on the following builds: Android Dev 63.0.3233.3 - 7.34 CPM, 113 reports, 26 clients (signature blink::scheduler::TaskQueue::Task::Task) If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates. - Go/Fracas
,
Oct 10 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8ece8f98a55044236a9e6e71a2c6034dbd078104 commit 8ece8f98a55044236a9e6e71a2c6034dbd078104 Author: Khushal <khushalsagar@chromium.org> Date: Tue Oct 10 23:46:37 2017 blink: Disallow advancing to incomplete frames for loaded images. Currently we would advance to an incomplete frame during an animation if the image was completely loaded (all_data_received). Looks like this was added in [1] to address a performance regression where querying whether a frame was complete would actually decode the frame. Since that is no longer true, the optimization is unnecessary. This also fixes a bug from an inconsistency in the logic at the beginning of StartAnimationInternal which allows advancing to incomplete frames if the image is completely loaded but the catch up code does not. This breaks the assumption after the catchup loop that at least one frame must have been advanced and can lead to infinite recursion. [1]: https://chromium.googlesource.com/chromium/src/+/9b1d01f53d289d611090038afcd910252985da7b%5E%21/#F1 R=chrishtr@chromium.org Bug: 771139 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ifd4de67068ab8dc521d9d2f16d54efe18fc58f4e Reviewed-on: https://chromium-review.googlesource.com/701671 Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Commit-Queue: Khushal <khushalsagar@chromium.org> Cr-Commit-Position: refs/heads/master@{#507827} [modify] https://crrev.com/8ece8f98a55044236a9e6e71a2c6034dbd078104/cc/trees/image_animation_controller.cc [modify] https://crrev.com/8ece8f98a55044236a9e6e71a2c6034dbd078104/cc/trees/image_animation_controller_unittest.cc [modify] https://crrev.com/8ece8f98a55044236a9e6e71a2c6034dbd078104/third_party/WebKit/Source/platform/graphics/BitmapImage.cpp [modify] https://crrev.com/8ece8f98a55044236a9e6e71a2c6034dbd078104/third_party/WebKit/Source/platform/graphics/BitmapImageTest.cpp
,
Oct 10 2017
,
Nov 7 2017
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by ClusterFuzz
, Oct 3 2017