Title: [246024] trunk/Source/_javascript_Core
- Revision
- 246024
- Author
- [email protected]
- Date
- 2019-06-02 15:18:06 -0700 (Sun, 02 Jun 2019)
Log Message
[JSC] Crash explicitly if StructureIDs are exhausted
https://bugs.webkit.org/show_bug.cgi?id=198467
Reviewed by Sam Weinig.
When StructureIDTable::m_size reaches to s_maximumNumberOfStructures, newCapacity in resize function is also capped with s_maximumNumberOfStructures.
So m_size == newCapacity. In that case, the following code in resize function, `makeFreeListFromRange(m_size, m_capacity - 1);` starts executing the
wrong code.
Currently, this is safe. We immediately execute the wrong code in makeFreeListFromRange, and crash with zero division. But we should not rely on
this crash, and instead we should explicitly crash because we exhaust StructureIDs.
This patch inserts RELEASE_ASSERT for `m_size < newCapacity` status to ensure that resize is always extending the table.
In practice, this crash does not happen in Safari because Safari has memory footprint limit. To exhaust StructureIDs, we need to allocate massive
amount of Structures, and it exceeds the memory footprint limit and the process will be killed.
* runtime/StructureIDTable.cpp:
(JSC::StructureIDTable::resize):
Modified Paths
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (246023 => 246024)
--- trunk/Source/_javascript_Core/ChangeLog 2019-06-02 20:51:57 UTC (rev 246023)
+++ trunk/Source/_javascript_Core/ChangeLog 2019-06-02 22:18:06 UTC (rev 246024)
@@ -1,3 +1,25 @@
+2019-06-02 Yusuke Suzuki <[email protected]>
+
+ [JSC] Crash explicitly if StructureIDs are exhausted
+ https://bugs.webkit.org/show_bug.cgi?id=198467
+
+ Reviewed by Sam Weinig.
+
+ When StructureIDTable::m_size reaches to s_maximumNumberOfStructures, newCapacity in resize function is also capped with s_maximumNumberOfStructures.
+ So m_size == newCapacity. In that case, the following code in resize function, `makeFreeListFromRange(m_size, m_capacity - 1);` starts executing the
+ wrong code.
+
+ Currently, this is safe. We immediately execute the wrong code in makeFreeListFromRange, and crash with zero division. But we should not rely on
+ this crash, and instead we should explicitly crash because we exhaust StructureIDs.
+
+ This patch inserts RELEASE_ASSERT for `m_size < newCapacity` status to ensure that resize is always extending the table.
+
+ In practice, this crash does not happen in Safari because Safari has memory footprint limit. To exhaust StructureIDs, we need to allocate massive
+ amount of Structures, and it exceeds the memory footprint limit and the process will be killed.
+
+ * runtime/StructureIDTable.cpp:
+ (JSC::StructureIDTable::resize):
+
2019-06-02 Keith Miller <[email protected]>
Reenable Gigacage on ARM64.
Modified: trunk/Source/_javascript_Core/runtime/StructureIDTable.cpp (246023 => 246024)
--- trunk/Source/_javascript_Core/runtime/StructureIDTable.cpp 2019-06-02 20:51:57 UTC (rev 246023)
+++ trunk/Source/_javascript_Core/runtime/StructureIDTable.cpp 2019-06-02 22:18:06 UTC (rev 246024)
@@ -102,6 +102,10 @@
if (newCapacity > s_maximumNumberOfStructures)
newCapacity = s_maximumNumberOfStructures;
+ // If m_size is already s_maximumNumberOfStructures, newCapacity becomes s_maximumNumberOfStructures in the above code.
+ // In that case, we should crash because of exhaust of StructureIDs.
+ RELEASE_ASSERT_WITH_MESSAGE(m_size < newCapacity, "Crash intentionally because of exhaust of StructureIDs.");
+
// Create the new table.
auto newTable = makeUniqueArray<StructureOrOffset>(newCapacity);
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
