Title: [200729] branches/safari-601-branch/Source/_javascript_Core
- Revision
- 200729
- Author
- matthew_han...@apple.com
- Date
- 2016-05-11 18:31:47 -0700 (Wed, 11 May 2016)
Log Message
Merge r196524. rdar://problem/26228552
Modified Paths
Diff
Modified: branches/safari-601-branch/Source/_javascript_Core/ChangeLog (200728 => 200729)
--- branches/safari-601-branch/Source/_javascript_Core/ChangeLog 2016-05-12 01:31:45 UTC (rev 200728)
+++ branches/safari-601-branch/Source/_javascript_Core/ChangeLog 2016-05-12 01:31:47 UTC (rev 200729)
@@ -1,3 +1,23 @@
+2016-05-11 Matthew Hanson <matthew_han...@apple.com>
+
+ Merge r196524. rdar://problem/26228552
+
+ 2016-02-12 Filip Pizlo <fpi...@apple.com>
+
+ 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 <matthew_han...@apple.com>
Merge r198592. rdar://problem/25332806
Modified: branches/safari-601-branch/Source/_javascript_Core/runtime/JSObject.cpp (200728 => 200729)
--- branches/safari-601-branch/Source/_javascript_Core/runtime/JSObject.cpp 2016-05-12 01:31:45 UTC (rev 200728)
+++ branches/safari-601-branch/Source/_javascript_Core/runtime/JSObject.cpp 2016-05-12 01:31:47 UTC (rev 200729)
@@ -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-branch/Source/_javascript_Core/runtime/StringPrototype.cpp (200728 => 200729)
--- branches/safari-601-branch/Source/_javascript_Core/runtime/StringPrototype.cpp 2016-05-12 01:31:45 UTC (rev 200728)
+++ branches/safari-601-branch/Source/_javascript_Core/runtime/StringPrototype.cpp 2016-05-12 01:31:47 UTC (rev 200729)
@@ -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
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
