A JSArray may have a filler map in the elements pointer.

We already have code that expects this, but incorrectly asserted that the
filler map case would never happen when allocation folding is turned on.
However, even folding has it's limits, bailing out of continued folding
when the object size grows too large. Therefore, it's a general problem
when verifying JSArray objects, that we might encounter a filler map
in elements().

Discovered by ClusterFuzz crbug 347903.

R=hpayer@chromium.org
LOG=N
BUG=347903

Review URL: https://codereview.chromium.org/184493002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19604 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

src/objects-debug.cc

@@ -264,8 +264,9 @@ void FixedTypedArray<Traits>::FixedTypedArrayVerify() {
 
 
 bool JSObject::ElementsAreSafeToExamine() {
-  return (FLAG_use_gvn && FLAG_use_allocation_folding) ||
-      reinterpret_cast<Map*>(elements()) !=
+  // If a GC was caused while constructing this object, the elements
+  // pointer may point to a one pointer filler map.
+  return reinterpret_cast<Map*>(elements()) !=
       GetHeap()->one_pointer_filler_map();
 }
 

test/mjsunit/regress/regress-crbug-347903.js

+// Copyright 2014 the V8 project authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+// Flags: --allow-natives-syntax --use-allocation-folding --verify-heap
+
+function f() {
+  var a = new Array(84632);
+  // Allocation folding will bail out trying to fold the elements alloc of
+  // array "b."
+  var b = new Array(84632);
+  var c = new Array(84632);
+  return [a, b, c];
+}
+f(); f();
+%OptimizeFunctionOnNextCall(f);
+for(var i = 0; i < 10; i++) {
+  f();
+}