to ishell for further investigation. Looks like this happened after an update of our toolchain.

LSAN found a leak of C++ memory through Collator object which is reachable from the native context which seems to be kept alive by one of the deferred handle scopes.

To make the issue explicit you may add this call to Runtime_CreateCollator function:
  isolate->heap()->AddRetainingPathTarget(local_object, RetainingPathOption::kDefault);

and run d8 with --track-retaining-path option.

I also noticed that the leak disappears with --predictable.

ClusterFuzz testcase 4898788846862336 is flaky and no longer crashes, so closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

I think it's worth fixing.

A shorter repro is

'퓛'.localeCompare();

I used the wrong commandline options, the repro has to be started with --invoke-weak-callbacks --omit-quit.

The problem is in the shutdown sequence of d8: The memory that is leaking here should be freed by the GC. However, it is kept alive by WebAssembly compilation. This means that if a GC happens after WebAssembly compilation stops, then the memory would get freed.

What's happening, however, is that first we call the GC, then we stop WebAssembly compilation, and then we notice that the memory did not get freed.

We cannot just do a GC call after stopping WebAssembly compilation though, because the heap is destroyed right after WebAssembly compilation is stopped in Isolate::Deinit. I guess we should not place a testing GC call in the middle of production code.

I see the following potential solutions:
1) Split up Isolate::Deinit so that in the first part we stop WebAssembly compilation, and in the second part we destruct the heap.
2) Allow the embedder (in this case d8) to register a callback which is called between stopping compilation and destructing the heap, so that the embedder can trigger a GC.
3) Add a TearDownWebAssemblyCompilationForTesting function which allows d8 to stop compilation before the first GC.

I tried 3), but it's more a hack than a convincing solution.

I like 1), if we give it a generic name like "PrepareTearDown" or something similar.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/825d0175681f3ddc83a9be6fb1d344546cb01146

commit 825d0175681f3ddc83a9be6fb1d344546cb01146
Author: Andreas Haas <ahaas@chromium.org>
Date: Mon Mar 12 16:46:42 2018

[intl] Store the collator as a Managed

The lifetime of the collator is handled by the JavaScript heap. At the
moment this is implemented with a weak GlobalHandle. With this CL I
change the implementation to use a Managed object instead. In addition I
did some code cleanup.

The main reason for using a Managed is an lsan problem. The final GC in
d8 is triggered before all pending WebAssembly compilations get
canceled. Via the native context, WebAssembly compilation can keep the
Collator wrapper alive, and therefore the collator is never deallocated.
Managed, however, get processed at isolate teardown, independent of the
reachability of the Managed.

TEST=mjsunit/regress/regress-813440

Bug:  chromium:813440 
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ie727eb1aff2144586eb36426cc44a32357c0f822
Reviewed-on: https://chromium-review.googlesource.com/956069
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51886}
[modify] https://crrev.com/825d0175681f3ddc83a9be6fb1d344546cb01146/src/objects/intl-objects.cc
[modify] https://crrev.com/825d0175681f3ddc83a9be6fb1d344546cb01146/src/objects/intl-objects.h
[modify] https://crrev.com/825d0175681f3ddc83a9be6fb1d344546cb01146/src/runtime/runtime-intl.cc
[add] https://crrev.com/825d0175681f3ddc83a9be6fb1d344546cb01146/test/mjsunit/regress/regress-813440.js

This issue should be fixed now.