Title: [271871] trunk
- Revision
- 271871
- Author
- wenson_hs...@apple.com
- Date
- 2021-01-25 17:30:04 -0800 (Mon, 25 Jan 2021)
Log Message
ASSERT NOT REACHED in WebCore::DisplayList::isDrawingItem
https://bugs.webkit.org/show_bug.cgi?id=220948
<rdar://problem/73588734>
Reviewed by Tim Horton.
Source/WebCore:
Additionally, fix a bug that is also caught when running this API test under debug. In the case where an out of
line item failed to decode (and is thus invalid), we still attempt to invoke its destructor when we're done
iterating, under `DisplayList::iterator::clearCurrentItem()`; we should not be doing this in the case where
`m_isValid` is `false`, since we already know that `m_currentBufferForItem` either contains an item that has
already been destroyed, or contains garbage data.
* platform/graphics/displaylists/DisplayList.cpp:
(WebCore::DisplayList::DisplayList::iterator::clearCurrentItem):
Tools:
The API test `DisplayListTests.OutOfLineItemDecodingFailure` was intended to read from the display list copy
rather than the original list, in order to exercise the (intentional) decoding failure.
Instead, this test erroneously attempts to read from the original display list (which, importantly, doesn't have
a reading client) and ends up exercising the decoding failure anyways, but additionally hits a debug assertion
in the process. Simply fix this by reading out of the correct display list (and rename the original display list
in the process to make the test more clear).
* TestWebKitAPI/Tests/WebCore/cg/DisplayListTestsCG.cpp:
(TestWebKitAPI::TEST)
Modified Paths
Diff
Modified: trunk/Source/WebCore/ChangeLog (271870 => 271871)
--- trunk/Source/WebCore/ChangeLog 2021-01-26 00:58:00 UTC (rev 271870)
+++ trunk/Source/WebCore/ChangeLog 2021-01-26 01:30:04 UTC (rev 271871)
@@ -1,3 +1,20 @@
+2021-01-25 Wenson Hsieh <wenson_hs...@apple.com>
+
+ ASSERT NOT REACHED in WebCore::DisplayList::isDrawingItem
+ https://bugs.webkit.org/show_bug.cgi?id=220948
+ <rdar://problem/73588734>
+
+ Reviewed by Tim Horton.
+
+ Additionally, fix a bug that is also caught when running this API test under debug. In the case where an out of
+ line item failed to decode (and is thus invalid), we still attempt to invoke its destructor when we're done
+ iterating, under `DisplayList::iterator::clearCurrentItem()`; we should not be doing this in the case where
+ `m_isValid` is `false`, since we already know that `m_currentBufferForItem` either contains an item that has
+ already been destroyed, or contains garbage data.
+
+ * platform/graphics/displaylists/DisplayList.cpp:
+ (WebCore::DisplayList::DisplayList::iterator::clearCurrentItem):
+
2021-01-25 Peng Liu <peng.l...@apple.com>
Twitter PiP video pauses when scrolling
Modified: trunk/Source/WebCore/platform/graphics/displaylists/DisplayList.cpp (271870 => 271871)
--- trunk/Source/WebCore/platform/graphics/displaylists/DisplayList.cpp 2021-01-26 00:58:00 UTC (rev 271870)
+++ trunk/Source/WebCore/platform/graphics/displaylists/DisplayList.cpp 2021-01-26 01:30:04 UTC (rev 271871)
@@ -383,7 +383,9 @@
void DisplayList::iterator::clearCurrentItem()
{
if (m_currentBufferForItem) {
- ItemHandle { m_currentBufferForItem }.destroy();
+ if (LIKELY(m_isValid))
+ ItemHandle { m_currentBufferForItem }.destroy();
+
if (UNLIKELY(m_currentBufferForItem != m_fixedBufferForCurrentItem))
fastFree(m_currentBufferForItem);
}
Modified: trunk/Tools/ChangeLog (271870 => 271871)
--- trunk/Tools/ChangeLog 2021-01-26 00:58:00 UTC (rev 271870)
+++ trunk/Tools/ChangeLog 2021-01-26 01:30:04 UTC (rev 271871)
@@ -1,3 +1,22 @@
+2021-01-25 Wenson Hsieh <wenson_hs...@apple.com>
+
+ ASSERT NOT REACHED in WebCore::DisplayList::isDrawingItem
+ https://bugs.webkit.org/show_bug.cgi?id=220948
+ <rdar://problem/73588734>
+
+ Reviewed by Tim Horton.
+
+ The API test `DisplayListTests.OutOfLineItemDecodingFailure` was intended to read from the display list copy
+ rather than the original list, in order to exercise the (intentional) decoding failure.
+
+ Instead, this test erroneously attempts to read from the original display list (which, importantly, doesn't have
+ a reading client) and ends up exercising the decoding failure anyways, but additionally hits a debug assertion
+ in the process. Simply fix this by reading out of the correct display list (and rename the original display list
+ in the process to make the test more clear).
+
+ * TestWebKitAPI/Tests/WebCore/cg/DisplayListTestsCG.cpp:
+ (TestWebKitAPI::TEST)
+
2021-01-25 Aakash Jain <aakash_j...@apple.com>
Changes to commit-log-editor should trigger webkitpy EWS tests
Modified: trunk/Tools/TestWebKitAPI/Tests/WebCore/cg/DisplayListTestsCG.cpp (271870 => 271871)
--- trunk/Tools/TestWebKitAPI/Tests/WebCore/cg/DisplayListTestsCG.cpp 2021-01-26 00:58:00 UTC (rev 271870)
+++ trunk/Tools/TestWebKitAPI/Tests/WebCore/cg/DisplayListTestsCG.cpp 2021-01-26 01:30:04 UTC (rev 271871)
@@ -112,22 +112,22 @@
auto cgContext = adoptCF(CGBitmapContextCreate(nullptr, contextWidth, contextHeight, 8, 4 * contextWidth, colorSpace.get(), kCGImageAlphaPremultipliedLast));
GraphicsContext context { cgContext.get() };
- DisplayList list;
+ DisplayList originalList;
WritingClient writer;
- list.setItemBufferClient(&writer);
+ originalList.setItemBufferClient(&writer);
Path path;
path.moveTo({ 10., 10. });
path.addLineTo({ 50., 50. });
path.addLineTo({ 10., 10. });
- list.append<SetInlineStrokeColor>(Color::blue);
- list.append<FillPath>(WTFMove(path));
+ originalList.append<SetInlineStrokeColor>(Color::blue);
+ originalList.append<FillPath>(WTFMove(path));
- DisplayList shallowCopy {{ ItemBufferHandle { globalBufferIdentifier, globalItemBuffer, list.sizeInBytes() } }};
+ DisplayList shallowCopy {{ ItemBufferHandle { globalBufferIdentifier, globalItemBuffer, originalList.sizeInBytes() } }};
ReadingClient reader;
shallowCopy.setItemBufferClient(&reader);
- Replayer replayer { context, list };
+ Replayer replayer { context, shallowCopy };
auto result = replayer.replay();
EXPECT_GT(result.numberOfBytesRead, 0U);
EXPECT_EQ(result.nextDestinationImageBuffer, WTF::nullopt);
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
