Title: [200753] branches/safari-601.1.46-branch/Source/_javascript_Core
- Revision
- 200753
- Author
- [email protected]
- Date
- 2016-05-12 02:12:08 -0700 (Thu, 12 May 2016)
Log Message
Merge r196524. rdar://problem/26228854
Modified Paths
Diff
Modified: branches/safari-601.1.46-branch/Source/_javascript_Core/ChangeLog (200752 => 200753)
--- branches/safari-601.1.46-branch/Source/_javascript_Core/ChangeLog 2016-05-12 09:12:05 UTC (rev 200752)
+++ branches/safari-601.1.46-branch/Source/_javascript_Core/ChangeLog 2016-05-12 09:12:08 UTC (rev 200753)
@@ -1,3 +1,23 @@
+2016-05-12 Matthew Hanson <[email protected]>
+
+ Merge r196524. rdar://problem/26228854
+
+ 2016-02-12 Filip Pizlo <[email protected]>
+
+ JSObject::putByIndexBeyondVectorLengthWithoutAttributes needs to go to the sparse map based on MAX_STORAGE_VECTOR_INDEX
+ https://bugs.webkit.org/show_bug.cgi?id=154201
+ rdar://problem/24291387
+
+ Reviewed by Saam Barati.
+
+ I decided against adding a test for this, because it runs for a very long time.
+
+ * runtime/JSObject.cpp:
+ (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes): Fix the bug.
+ * runtime/StringPrototype.cpp:
+ (JSC::stringProtoFuncSplit): Fix a related bug: if this code creates an array that would have
+ hit the above bug, then it would probably manifest as a spin or as swapping.
+
2016-03-24 Matthew Hanson <[email protected]>
Merge r198592. rdar://problem/25271136
Modified: branches/safari-601.1.46-branch/Source/_javascript_Core/runtime/JSObject.cpp (200752 => 200753)
--- branches/safari-601.1.46-branch/Source/_javascript_Core/runtime/JSObject.cpp 2016-05-12 09:12:05 UTC (rev 200752)
+++ branches/safari-601.1.46-branch/Source/_javascript_Core/runtime/JSObject.cpp 2016-05-12 09:12:08 UTC (rev 200753)
@@ -1932,7 +1932,7 @@
VM& vm = exec->vm();
- if (i >= MAX_ARRAY_INDEX - 1
+ if (i > MAX_STORAGE_VECTOR_INDEX
|| (i >= MIN_SPARSE_ARRAY_INDEX
&& !isDenseEnoughForVector(i, countElements<indexingShape>(butterfly())))
|| indexIsSufficientlyBeyondLengthForSparseMap(i, m_butterfly->vectorLength())) {
Modified: branches/safari-601.1.46-branch/Source/_javascript_Core/runtime/StringPrototype.cpp (200752 => 200753)
--- branches/safari-601.1.46-branch/Source/_javascript_Core/runtime/StringPrototype.cpp 2016-05-12 09:12:05 UTC (rev 200752)
+++ branches/safari-601.1.46-branch/Source/_javascript_Core/runtime/StringPrototype.cpp 2016-05-12 09:12:08 UTC (rev 200753)
@@ -1182,8 +1182,23 @@
// 3. Increment lengthA by 1.
// 4. If lengthA == lim, return A.
- if (++resultLength == limit)
+ ++resultLength;
+ if (resultLength == limit)
return JSValue::encode(result);
+ if (resultLength >= MAX_STORAGE_VECTOR_INDEX) {
+ // Let's consider what's best for users here. We're about to increase the length of
+ // the split array beyond the maximum length that we can support efficiently. This
+ // will cause us to use a HashMap for the new entries after this point. That's going
+ // to result in a very long running time of this function and very large memory
+ // usage. In my experiments, JSC will sit spinning for minutes after getting here and
+ // it was using >4GB of memory and eventually grew to 8GB. It kept running without
+ // finishing until I killed it. That's probably not what the user wanted. The user,
+ // or the program that the user is running, probably made a mistake by calling this
+ // method in such a way that it resulted in such an obnoxious array. Therefore, to
+ // protect ourselves, we bail at this point.
+ throwOutOfMemoryError(exec);
+ return JSValue::encode(jsUndefined());
+ }
// 5. Let p = e.
// 8. Let q = p.
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
