There's no bug on this yet - I ran across this when I ran out of memory in my SharedWorkers soak test I was running (turns out that this bug may be unrelated to the SharedWorkers bug).
It's quite possible that this is related to the V8GCController code - I'd forgotten about that. In fact, it's quite possible that the true cause is "ports are not getting closed when their parent document exits", in which case leaking the port is the expected behavior. I'll look at this a bit more - thanks for the pointer. -atw On Thu, Nov 19, 2009 at 2:35 PM, Vitaly Repeshko <vita...@chromium.org>wrote: > On Fri, Nov 20, 2009 at 1:20 AM, Drew Wilson <atwil...@chromium.org> > wrote: > > I'm investigating a leak in the MessagePort/MessageChannel code. > Basically, > > if I have a page that looks like this: > > <script> > > new MessageChannel(); > > </script> > > We leak two MessagePorts every time we reload the page. > > The WebCore::MessageChannel impl object has two RefPtrs to two > MessagePort > > objects. When I reload the page, the MessageChannel DOMWrapper V8 object > is > > GC'd, leading to the MessageChannel impl object getting deref'd and > freed. > > The problem is that the V8 MessageChannel constructor has this code: > > > > // Create references from the MessageChannel wrapper to the two > > // MessagePort wrappers to make sure that the MessagePort wrappers > > // stay alive as long as the MessageChannel wrapper is around. > > messageChannel->SetInternalField(kMessageChannelPort1Index, > > V8DOMWrapper::convertToV8Object(V8ClassIndex::MESSAGEPORT, > obj->port1())); > > messageChannel->SetInternalField(kMessageChannelPort2Index, > > V8DOMWrapper::convertToV8Object(V8ClassIndex::MESSAGEPORT, > obj->port2())); > > // Setup the standard wrapper object internal fields. > > V8DOMWrapper::setDOMWrapper(messageChannel, > > V8ClassIndex::MESSAGECHANNEL, obj.get()); > > Those two MessagePort DOMWrappers don't seem to get freed, so they hold a > > reference to the underlying MessagePort impl objects. > > There are a few things I don't understand here: > > 1) I don't get why we need to explicitly keep a special reference to the > > MessagePorts here in internal fields - we don't seem to do that for other > > DOM Wrappers that have references like this (e.g. SharedWorker.port). > > There are a few corner-cases where we have to create additional links > in JS world to prevent things from being collected. Another example of > this are hidden dependencies that are used to keep event listeners on > DOM objects alive. IIRC, there is another part of this in > V8GCController dealing with message ports. Perhaps these two parts > conflict. > > > 2) Is there a good way to figure out why the garbage collector isn't > > collecting these references also, short of stepping through the V8 GC > code? > > How do people typically track this stuff? > > Any pointers would be much appreciated. > > You could try using DevTools heap profiler. Alternatively in debug > mode there is TracePathToObject() (see > > http://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/heap.cc#3853 > ). > > Is there a bug on this? I'm happy to have a look and fix it. > > > -- Vitaly > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
