[Webkit-unassigned] [Bug 193291] Leak of WTF::StringImpl under SymbolImpl::createNullSymbol() (48 bytes) in com.apple.WebKit.WebContent running layout tests

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=193291

--- Comment #20 from David Kilzer (:ddkilzer) <ddkilzer at webkit.org> ---
(In reply to Yusuke Suzuki from comment #17)
> (In reply to David Kilzer (:ddkilzer) from comment #12)
> > (In reply to Yusuke Suzuki from comment #11)
> > > https://bugs.webkit.org/show_bug.cgi?id=194082 I think this is the cause of
> > > this issue.
> > 
> > It's not the direct cause, but it did help me to find the root cause.
> > 
> > SymbolImpl() needs a destructor to call StringImpl::deref() on `m_owner`
> > since 2 of 3 SymbolImpl constructors leak a StringImpl ref to store the
> > pointer value.
> 
> I have two questions.
> 
> 1. Why is deref() for m_owner necessary? StringImpl::~StringImpl's
> BufferSubstring code calls it. SymbolImpl always sets BufferSubString
> ownership so that this deref() breaks the balance. Is it right?
> 2. Is this destructor actually called? StringImpl and SymbolImpl do not have
> virtual destructor. Who calls this destructor?

I was unable to break on ~SymbolImpl with either Release or Debug builds using lldb, so there is clearly something wrong with my patch (which is also why I rolled it out yesterday).  Also, if ~SymbolImpl isn't getting called, I can't explain why it fixes the leaks!

(I had assumed that when a JSC::PrivateName object was destructed via JSC::Symbol::~Symbol(), it would deref JSC::PrivateName::m_uid, and then that WTF::SymbolImpl would be destructed when its ref count reached zero.  FWIW, neither JSC::Symbol nor JSC::PrivateName have destructors declared, although I had assumed they'd get default destructors in that case.  Note that JSC::Symbol::destroy() does call JSC::Symbol::~Symbol().)

Maybe this is a false-positive leak of some sort?  If so, it would be good to figure out if we can avoid the false-positive so it's easier to notice true leaks in the WebContent process.

(I've run out of time to spend investigating this again, hence unassigning the bug.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190204/d9768b76/attachment.html>