No CL in the regression range changes the crashed files. The result is the blame information.

Author: cevans@chromium.org
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src//+/b1b670e62e1523f2037c3ea031e530e997ed23aa
Time: Mon Aug 26 19:56:49 2013
The CL last changed line 736 of file PartitionAlloc.h, which is stack frame 1.

Author: ruuda
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src//+/006dc1e53075a580f789a2b18f7a47316e217dc7
Time: Tue Dec 01 18:43:11 2015
The CL last changed line 763 of file PartitionAlloc.h, which is stack frame 2.

Author: ruuda
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src//+/006dc1e53075a580f789a2b18f7a47316e217dc7
Time: Tue Dec 01 18:43:11 2015
The CL last changed line 98 of file Partitions.h, which is stack frame 3.

Author: ruuda
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src//+/ba2eebd19776527566625c066495dd31565b0002
Time: Wed Dec 02 12:22:16 2015
The CL last changed line 299 of file StringImpl.cpp, which is stack frame 4.

Author: darin@apple.com
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src//+/3662ceae1a29c7a6588d05a3597c2843dfd618bb
Time: Fri Nov 12 01:01:14 2010
The CL last changed line 407 of file StringImpl.cpp, which is stack frame 5.

Author: abarth@chromium.org
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src//+/c0a99c9896b2a735b2d1fcd7b49936981c153ac1
Time: Sat Aug 03 03:57:01 2013
The CL last changed line 766 of file StringImpl.h, which is stack frame 6.

Author: ggaren@apple.com
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src//+/10499802a104a526c438e9892c9e720a76b876c8
Time: Tue Oct 25 03:54:15 2011
The CL last changed line 648 of file WTFString.cpp, which is stack frame 7.

Suspected Project: chromium
======================

From the above CLs the changes made to the file "Partitions.h" of frame 2 & 3 are more related to it.Hence assigning to @ ruuda

Unable to assign to @ruuda,hence assigning to reviewer of the CL,Please help us in assinging this to appropriate owner for this issue.

Thanks,

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Let's move this on the triage queue.

Looks like this is leaking MediaValuesCached mediaType.

Hm, I reprod with the given build, but when I tried at Linux TOT (#405981) LSAN reported a LOT of leaks. Too many to be really actionable and it makes me question the report.

Might look into reproing on Mac if I have time.

LSAN is supported only on x86_64 linux, I couldn't build this on my local Mac (and I don't have good access to other machines right now :( ). kouhei@, yoav@ or csharrison@ do you think either of you could look into this one further and see if it's a real issue we need to fix?

on TOTT (#408635) I ran this:
ASAN_OPTIONS="detect_leaks=1 symbolize=1" python ~/clusterfuzz/src/tools/on_demand/run_gestures_on_device_local.py --config ~/Downloads/config_6703427791093760.zip --build ~/chromium/src/out/asan/ --verbose

with args.gn:
is_asan = true
enable_nacl = false
is_debug = false
use_goma = true

and I feel like LSAN thinks we practically leaked the entire render process. Attached is the dump.

Deleted: leak_results_symbolized.txt 5.3 MB

leak_results_symbolized.txt 5.3 MB View Download

+inferno, is there a precedent to LSAN leak explosions in the renderer? I'm not sure what to make of this.

It's leaking a Document, so expect to see all the allocations that's reachable from it in the report. Notice that Document itself won't be reported as a leak, as it is in the Oilpan heap, which we don't attempt to have cleaned out completely before LSan kicks in.

The testcase might show a leak with the LeakDetector also, given that it is a document? --enable-leak-detection w/out LSan to find out.

sigbjornf@, thanks for the insight. I reproduced with ASAN_OPTIONS="detect_leaks=0" and passing --enable-leak-detection into the testcase config.

I received a very similar leak result with those parameters.

What is the real difference here? Seems like --enable-leak-detection is still seeing the (fake) Document leak. 

random idea from your friendly bug triage: could this be a heap corruption that reveals itself as a leak? Could we feed the same testcase to the regular ASan?

csharrison: since you already invested some time into it, can you please triage it further? (comment #11 contains a lame idea:)

Yeah no problem. I don't have an asan build handy with me right now but I think I tried that and it didn't find anything until I added --enable-leak-detection or LSAN options.

ClusterFuzz has detected this issue as fixed in range 411875:411885.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=6703427791093760

Fuzzer: bj_broddelwerk
Job Type: linux_lsan_chrome_mp
Platform Id: linux

Crash Type: Direct-leak
Crash Address: 
Crash State:
  std::__1::unique_ptr<WTF::Function<base::internal::MakeUnboundRunTypeImpl<void
  blink::HTMLDocumentParser::startBackgroundParser
  blink::HTMLDocumentParser::appendBytes
  
Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_lsan_chrome_mp&range=396459:396493
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_lsan_chrome_mp&range=411875:411885

Unminimized Testcase: https://cluster-fuzz.appspot.com/download/AMIfv96QtD4i1vF9LiQegeu3IfTku3kD8e9nkXyU8LKATdiMnaBuXfUGkdDPNQh8NYsS-FDz5D2yCOyBNQUTBG_76H-SY0rxErGnyDvbrvGluP2kg3BreG6XNQBXui12IvbFoSYrMC7fFg49g7YOMfnB_Uo9f8dVTnux0gHceaRsq7EjYfxDSyI?testcase_id=6703427791093760


Additional requirements: Requires Gestures

See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs 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 is verified as fixed, closing issue.

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

So, this wrong. The fixed range shows has:
https://codereview.chromium.org/2221193002 

Which adds testing configs to put the BackgroundHTMLParser on the main thread on bots. I don't think this should be marked as fixed until that experiment lands on HEAD.

The test case should still repro locally.

Removing EditIssue view restrictions from ClusterFuzz filed bugs. If you believe that this issue should still be restricted, please reapply the label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

And, the experiment landed.