Regression range only contains f554b1544f1c1d6a3360472366720667aa5480d2	(Reland "[d8] implement setTimeout.").

The last time we had this report ( crbug.com/734409 ), it looked very unrelated to the CL in the regression range at first, but then it turned out that we really keep too many objects alive by creating a cycle of weak global handles. That was fixed then, and the leak disappeared.

Maybe your CL also keeps something alive on the heap?

Automatically applying components based on information from OWNERS files. If this seems incorrect, please apply the Test-Predator-Wrong-Components label.

ClusterFuzz has detected this issue as fixed in range 49103:49104.

Detailed report: https://clusterfuzz.com/testcase?key=6126516915404800

Fuzzer: v8_builtins_generator
Job Type: mac_asan_d8_dbg
Platform Id: mac

Crash Type: Direct-leak
Crash Address: 
Crash State:
  uprv_malloc_59
  icu_59::UMemory::operator new
  v8::internal::CreateICUDateFormat
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=mac_asan_d8_dbg&range=47810:47811
Fixed: https://clusterfuzz.com/revisions?job=mac_asan_d8_dbg&range=49103:49104

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=6126516915404800

See https://github.com/google/clusterfuzz-tools for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 6126516915404800 is verified as fixed, so closing issue as verified.

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