Separate unpacked SerializedScriptValue contents and correct lifetime.
In a previous CL [1], unpacked contents were stored in the
SerializedScriptValue object itself, in order to make sure that the
received contents can be used to deserialize a MessageEvent's data
in multiple worlds.
These objects (SerializedScriptValue::received_) are held by
persistent handles into the Oilpan thread heap. However,
SerializedScriptValue is ThreadSafeRefCounted, and it is possible for
the last reference to be dropped on another thread (e.g. the sending
thread), which results in the persistent node being returned to the
wrong thread's persistent region.
This CL corrects this by splitting this "unpacking" process into an
explicit step, which creates another object
(UnpackedSerializedScriptValue) with separately managed lifetime on
the receiving thread. Unpacking can only happen once, since it
consumes the transferred object contents.
This object is held by any object which may need to deserialize an
unpacked object twice (at present, only MessageEvent), and will not
be referenced from any other thread.
Since there are a number of uses of SerializedScriptValue that do
not support transfer, these are left alone and correctness is
confirmed using DCHECKs that a value is unpacked only once, and is
unpacked before deserialization if there are transferred contents.
A unit test which uses a worker thread to replicate the problematic
conditions is included.
[1]: https://chromium.googlesource.com/chromium/src/+/4bcb9954
Bug: 728017
Change-Id: Id9690cd7b24fcf922f4ef561c54c7a1e7c648d89
Reviewed-on: https://chromium-review.googlesource.com/540535
Commit-Queue: Jeremy Roman <[email protected]>
Reviewed-by: Kentaro Hara <[email protected]>
Cr-Commit-Position: refs/heads/master@{#484706}17 files changed
