Handle store buffer slot overwrite during object promotion.

The bad scenario this fix handles:

We have a slot in a free list, then promote the object pointed-to by
the slot during scavenge. When allocating the space for the promoted
object, we overwrite the slot with the free list entry map if the
object is allocated just before the slot. After the allocation,
ScavengingVisitor::PromoteObject overwrites the slot with the
address of the allocated object, thus corrupting the free list.

Unfortunately, we do not have a way to construct a reliable repro
case because we would need to somehow craft a free list and store
buffer slot to be in the right configuration.

R=hpayer@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#25143}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25143 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

diff --git a/src/heap/heap.cc b/src/heap/heap.cc
index 5c8cd45..c4eed9c 100644 (file)
--- a/src/heap/heap.cc
+++ b/src/heap/heap.cc
@@ -2038,7 +2038,17 @@ class ScavengingVisitor : public StaticVisitorBase {
       // Order is important: slot might be inside of the target if target
       // was allocated over a dead object and slot comes from the store
       // buffer.
-      *slot = target;
+
+      // Unfortunately, the allocation can also write over the slot if the slot
+      // was in free space and the allocation wrote free list data (such as the
+      // free list map or entry size) over the slot.  We guard against this by
+      // checking that the slot still points to the object being moved.  This
+      // should be sufficient because neither the free list map nor the free
+      // list entry size should look like a new space pointer (the former is an
+      // old space pointer, the latter is word-aligned).
+      if (*slot == object) {
+        *slot = target;
+      }
       MigrateObject(heap, object, target, object_size);
 
       if (object_contents == POINTER_OBJECT) {