New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 801484 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Garbage not collected when ArrayBuffer is transferred to a worker using postMessage

Project Member Reported by mlippautz@chromium.org, Jan 12 2018

Issue description

This likely has to do with the fact that external memory accounted is not properly transferred to the worker.
 
postmessage-leak.html
604 bytes View Download
Issue 801147 has been merged into this issue.
Cc: hpayer@chromium.org u...@chromium.org yujieqin@google.com
Status: Started (was: Assigned)
Cc: jbroman@chromium.org
CCing a few people that could know more.
False alarm here: Transferring decrements on the source isolate and increments on the target isolate. 

Checking GC scheduling next.
Double-checked accounting and it seems off. What I am seeing for the repro
...
0x372e104e5000 Change: 11520000
0x372e104e5000 Change: 11520000
0x372e104e5000 Change: -11520000
...

First pointer is Isolate. So even though we are decrementing and incrementing the count, it is always on the same Isolate. That seems wrong.
jbroman: I think the registering is happening on the wrong Isolate, or maybe just a bit too early.

See https://cs.chromium.org/chromium/src/third_party/WebKit/Source/bindings/core/v8/serialization/SerializedScriptValue.cpp?type=cs&l=586

- Ideally we would explicitly register on the target Isolate. 
- If that is not possible, we need to find a different location where Current::Isolate is the actual target? 



It may also be the call a bit below [1] gets the wrong Isolate. Waiting for jbroman@ to clarify.

[1] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/bindings/core/v8/serialization/SerializedScriptValue.cpp?type=cs&l=590
https://chromium.googlesource.com/chromium/src/+/e75f1381dccdeef00b30479ad55432f60ee8db7d was the last time we looked at this. I would cc sigbjornf@opera.com, but it seems like he's not working on Chromium anymore.
CL: https://chromium-review.googlesource.com/c/chromium/src/+/868019

Bug:
Upon unpacking a SerializedScriptValue into an
UnpackedSerializedScriptValue we also move the ArrayBufferContents to
the unpacked value. Subsequent calls to
RegisterMemoryAllocatedWithCurrentScriptContext will not find the
contents object and thus fail to re-register external memory.
Project Member

Comment 11 by bugdroid1@chromium.org, Jan 17 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/da7248b830fcf503ab0fd0e4292c367bb5244ab9

commit da7248b830fcf503ab0fd0e4292c367bb5244ab9
Author: Michael Lippautz <mlippautz@chromium.org>
Date: Wed Jan 17 14:37:16 2018

[bindings] Fix external memory accounting for SerializedScriptValue

Upon unpacking a SerializedScriptValue into an
UnpackedSerializedScriptValue we also move the ArrayBufferContents to
the unpacked value. Subsequent calls to
RegisterMemoryAllocatedWithCurrentScriptContext will not find the
contents object and thus fail to re-register external memory.

This CL moves re-registering into the unpacking step.

Bug:  801484 
Change-Id: If4fa5082579629fb5f4c3c0666e704bd14bb5ec0
Reviewed-on: https://chromium-review.googlesource.com/868019
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#529738}
[modify] https://crrev.com/da7248b830fcf503ab0fd0e4292c367bb5244ab9/third_party/WebKit/Source/bindings/core/v8/serialization/UnpackedSerializedScriptValue.cpp
[modify] https://crrev.com/da7248b830fcf503ab0fd0e4292c367bb5244ab9/third_party/WebKit/Source/core/events/MessageEvent.cpp

Status: Fixed (was: Started)
Bug should be fixed. The refactoring problem is tracked in issue 803079.

Sign in to add a comment