Predator and CL could not provide any possible suspects.

Using Code Search for the file, "MessagePort.cpp" and observed some recent changes for the below file.

Suspect CL: https://chromium.googlesource.com/chromium/src/+/6dc8a881789007e9305415c9875a90a3fd023962%5E%21/third_party/WebKit/Source/core/dom/MessagePort.cpp

mek@ -- Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks!

Not sure I understand the supposed leak. Am I reading the report correctly that this is complaining that the mojo::Connector created by make_unique in Entangle is somehow leaked? Not sure how that would be possible, given that it is owned by a std::unique_ptr. The only way that could leak would be if the MessagePort that owns it is also leaked, but it doesn't seem to be complaining about that?

Any idea what I'm missing here?

Some of our leak detection tools don't see Oilpan objects very well, so sometimes leaks are detected via the non-Oilpan objects that are owned that way.

I think we also have issues with leak detection not doing a GC on workers before checking, so sometimes we have memory that would be collected on the next major GC. The stack trace makes me suspect that's what's happening here, but I haven't dug into this one deeply.

Yeah, definitely looks like this is a case of MessagePort not getting GC'ed even though it should be able to be GC'ed. Clearly close() was called on the port (since it's in the allocation trace), so closed_ would be true, and thus IsEntangled() would be false, and HasPendingActivity would also be false.

So the bug (if anything) seems to be in how GC'ed object are accounted for in these leak detections.

Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

 Issue 823038  has been merged into this issue.

Marking as won't-fix since to the best of my knowledge there is no memory leak here, and this is just a bug in the leak detection code...

ClusterFuzz testcase 5256490332717056 is still reproducing on tip-of-tree build (trunk).

If this testcase was not reproducible locally or unworkable, ignore this notification and we will file another bug soon with hopefully a better and workable testcase.

Otherwise, if this is not intended to be fixed (e.g. this is an intentional crash), please add ClusterFuzz-Ignore label to prevent future bug filing with similar crash stacktrace.