Fix memory leak on serializing neutered ArrayBuffer.

Source/bindings/v8/SerializedScriptValue.cpp

Index: Source/bindings/v8/SerializedScriptValue.cpp
diff --git a/Source/bindings/v8/SerializedScriptValue.cpp b/Source/bindings/v8/SerializedScriptValue.cpp
index 984d5e7388c81401ba571f73baad30d1c1c07b9e..5532cb991d7cc2ae927316a46dfae5037d1e9f51 100644
--- a/Source/bindings/v8/SerializedScriptValue.cpp
+++ b/Source/bindings/v8/SerializedScriptValue.cpp
@@ -1139,9 +1139,11 @@ private:
         v8::Handle<v8::Value> underlyingBuffer = toV8(arrayBufferView->buffer(), v8::Handle<v8::Object>(), m_writer.getIsolate());
         if (underlyingBuffer.IsEmpty())
             return handleError(DataCloneError, next);
-        StateBase* stateOut = doSerialize(underlyingBuffer, 0);
-        if (stateOut)
+        if (StateBase* stateOut = doSerialize(underlyingBuffer, 0)) {

[Dmitry Lomov (no reviews), 2013/11/04 10:15:35]

style nit: I am a simple programmer and variable declarations inside if
conditions frighten and confuse me. 
Please move the declaration outside if statement (I know other similar
statements in this file follow this style, but this is just WebKit legacy - feel
free to change the other occurences too too)

[sof, 2013/11/04 10:21:14]

alright. One of the likeable syntactic features of c++, imo.

+            while (stateOut)
+                stateOut = pop(stateOut);

[Dmitry Lomov (no reviews), 2013/11/04 10:15:35]

Hmm I do not like this popping out loop (It repeats what happens in
handleError). If I understand correctly, the correct fix here would be to pass
'next' into doSerialize (instead of 0 second parameter) and then just return the
result if if it is non-null.

[sof, 2013/11/04 10:21:14]

Hmm, and we won't run into the depth check at the front of doSerialize() by
propagating the stack (represented by 'next')?

             return handleError(DataCloneError, next);
+        }
         m_writer.writeArrayBufferView(*arrayBufferView);
         // This should be safe: we serialize something that we know to be a wrapper (see
         // the toV8 call above), so the call to doSerialize above should neither cause