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

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

Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/a97e4b274530e17656f7d493f4eb950502311e08 (Encode Subject header correctly per RFC 2047).

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label. If you aren't the correct owner for this issue, please unassign yourself as soon as possible so it can be re-triaged.

My CL did not touch any files listed in the crash stack.

Predator and CL could not provide any possible suspects.
Using the code search for the file, “long_task_detector.cc” assigning to concern owner from GIT blame.

Suspecting Commit#
https://chromium.googlesource.com/chromium/src/+/91c1b85524d974f3b9ca143f4da5695b5448f7a8

@npm -- Could you please look into this issue, kindly reassign if it has nothing to do with your changes.
Thank You.

This is not caused by my change but the stacktrace for the direct leak is strange... +dproy@ maybe has an idea on what could be going on.

Can TimeTicks be used with PODInterval? I'm guessing TimeTicks is not a POD, but I don't know if it satisfies the requirements of PODInterval. Talking about this line: https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/loader/interactive_detector.h?l=120&rcl=e1e8576ba346bf0aba99f860853e835975dffc06

It does say this:

// *Note* that the destructors of type T and UserData will *not* be
// called by this class. They must not allocate any memory that is
// required to be cleaned up in their destructors.

TimeTicks does need to clean up after itself, so the vector destructor is probably just destroying the PODInterval but not the TimeTicks inside it.

That makes sense. Do you have time to take this on? I'm guessing the solution here is to either convert the TimeTicks to double, or write our own little interval class (we don't seem to have one in base.)

Ok assigning to myself.

Actually I think PODInterval works because it has T members low_ and high_, so the destructors should be called (not sure why the comment). The latest stacktrace does not show OnLongTaskDetected. Could we get this triaged using the new stacktrace?

ClusterFuzz has detected this issue as fixed in range 566300:566302.

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

Fuzzer: attekett_dom_fuzzer
Job Type: linux_lsan_chrome_mp
Platform Id: linux

Crash Type: Direct-leak
Crash Address: 
Crash State:
  blink::InteractiveDetector::OnLongTaskDetected
  blink::LongTaskDetector::DidProcessTask
  base::sequence_manager::TaskQueueManagerImpl::NotifyDidProcessTask
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_lsan_chrome_mp&range=530370:530375
Fixed: https://clusterfuzz.com/revisions?job=linux_lsan_chrome_mp&range=566300:566302

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

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 4593442764881920 is verified as fixed, so closing issue as verified.

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