Reproduces with this little one-liner, since at least 09/2016:

new Intl.DateTimeFormat();

--> SUMMARY: AddressSanitizer: 23822 byte(s) leaked in 38 allocation(s).

@littledan: You were last person that touched intl stuff, can you take a look please, or reassign? Thanks!

Working on reproducing it, thanks for triaging it to me.

To reproduce, build a debug asan d8 with these gn flags:
is_asan = true
is_component_build = false
is_debug = true
is_lsan = true
use_goma = true
target_cpu = "x64"

Then, set ASAN_OPTIONS, e.g. like this (the most important one is probably "detect_leaks=1"):
export ASAN_OPTIONS=redzone=128:symbolize=0:detect_stack_use_after_return=1:alloc_dealloc_mismatch=0:detect_leaks=1:print_scariness=1:check_malloc_usable_size=0:max_uar_stack_size_log=16:use_sigaltstack=1:handle_abort=1:strict_memcmp=0:detect_container_overflow=0:coverage=0:detect_odr_violation=0:allocator_may_return_null=1:handle_sigill=1:handle_segv=1:fast_unwind_on_fatal=1

Then, run d8 with the reproducer from above:
out/Debug.asan/d8 -e 'new Intl.DateTimeFormat();'

Thanks for the reproduction instructions. They worked for me.

It seems like the leak occurs when exiting V8 before performing a GC. I can see, when running it interactively, that the DeleteDateFormat call, which is supposed to free the data that's leaking, is never reached. However, after an explicit call to gc(), DeleteDateFormat is reached, and there is no leak.

I was under the impression that GC and various other kinds of cleanup might not be performed on shutdown because typically, we'll be discarding the whole process. Is that the case? If so, it might not be a problem to "leak" these ICU-allocated objects.

Michael, as explained above, I believe this is not a bug but rather an artifact of the infrastructure. Is there some general way we could categorize reports like this in the future more automatically?

I asked the question elsewhere: Why are we detecting leaks on mac asan if we're not doing it on the main waterfall in the first place? What prevents us from doing it there? Or is this issue also happening on linux?

Otherwise, I have no good suggestion for what to do with this kind of leaks. I have no insights in how the sanitizers work in regards to our shutdown. Maybe forward this to v8-dev?

One thing maybe: Our test runner also passes two additional flags for testing with asan on the main waterfall:
https://cs.chromium.org/chromium/src/v8/tools/run-tests.py?q=%22--omit-quit%22+package:%5Echromium$&l=546
Does this still repro with d8 when --invoke-weak-callbacks and --omit-quit is passed?

--invoke-weak-callbacks makes the leak not happen. This makes sense, since it's weak callbacks that are responsible for freeing the data. Should we add this flag to CF ASAN runs?

(--omit-quit seems to have no effect)

Offline discussion with mstarzinger (+jochen who added the --invoke-weak-callbacks flag):
The flag --invoke-weak-callbacks should be added on all jobs using lsan to not produce extra noise coming from untidy weak links. Real leaks will still be found when passing the flag.

We already pass the flag on all ASAN jobs in APP_ARGS list, but not in REQUIRED_APP_ARGS list. So I assume the fuzzer fuzzed it away in this bug.

I'll do the changes to the jobs. Not sure what to do with bugs like this. Maybe just set to Wontfix? And manually set the underlying clusterfuzz test case to fixed?

 Issue 728019  has been merged into this issue.

 Issue 728018  has been merged into this issue.

As machenbach recommended, I manually set the ClusterFuzz test cases to fixed; I look forward to seeing more bug reports that aren't spurious in this code :)

ClusterFuzz testcase 4916694501031936 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.

As noted above, the CF test is invalid, as it uses flag settings which are expected to leak data.