Assigning to concern owner from Predator results --
Regression information is not available. The result is the blame information. 

Author: jam
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/4a1511ef45627b827c47a34a65aee06028d71d3a
Time: Thu Feb 19 20:29:17 2015
The CL last changed line 647 of file web_url_loader_impl.cc, which is stack frame 0. 

Author: jam@chromium.org
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/4db58d7f39fa1714a498d04280e5bd6891608ecb
Time: Mon Mar 24 17:05:19 2014
The CL last changed line 1272 of file web_url_loader_impl.cc, which is stack frame 1. 

Author: yhirano
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/30a9d55c7e1c0ed1d6f005999c07fd7d1ef738b9
Time: Wed Apr 12 07:34:35 2017
The CL last changed line 174 of file ImageResource.cpp, which is stack frame 5. 

Author: yhirano
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/30a9d55c7e1c0ed1d6f005999c07fd7d1ef738b9
Time: Wed Apr 12 07:34:35 2017
The CL last changed line 196 of file DocumentLoader.cpp, which is stack frame 6.

@yhirano -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

I failed to reproduce the issue locally. Clusterfuzz failed to bisect the crash. None of the CLs listed in #1 doesn't match the regression range.

Redo task has been performed for new regression range.
Thank You.

No possible suspects were identified even after redo task has been performed. All the suspects are related to the owner assigned in Comment# 1.
Adding CF-NeedsTriage label for further inputs on the issue. Please mark as Won't Fix if the issue is not reproducible.
Thank You.

yhirano@, could you please add a comment why this is WontFix? Thanks!

Also note that we are going to temporary disable that fuzzer on ClusterFuzz side because it's very slow and in 80+% of runs it triggers this particular crash: https://clusterfuzz.com/v2/performance-report/libFuzzer_renderer_tree_fuzzer/libfuzzer_chrome_asan/2017-09-29

But the fuzzer will stay in Chromium tree, so you always can build it locally to reproduce and to verify the fix.

You can reproduce this crash painlessly with our reproduce tool. For Googlers, install the required libraries and run prodaccess && /google/data/ro/teams/clusterfuzz-tools/releases/clusterfuzz reproduce 6319943296745472. For non-Googlers, see the installation section. Report any issues at clusterfuzz-dev@chromium.org.


For manual reproducing, please see https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md

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

Thank you for telling me how to reproduce the crash. I can reproduce the crash now.

It crashes because the fuzzer runs the code in a broken environment. It loads an HTML "<img src=';'></img>" and it triggers a preload scanner which requests ";". But as the fuzzer doesn't initializer the resource loading module correctly (ChildThreadImpl::current() returns null) blink crashes. Hence I think this is not a blink bug but a fuzzer bug.

By the way, https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md returns 404.

ClusterFuzz has detected this issue as fixed in range 505670:505719.

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

Fuzzer: libFuzzer_renderer_tree_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x000000000000
Crash State:
  content::WebURLLoaderImpl::Context::Start
  content::WebURLLoaderImpl::LoadAsynchronously
  blink::ResourceLoader::StartWith
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=408165:408299
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=505670:505719

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

See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md 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 6319943296745472 is verified as fixed, so closing issue as verified.

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

https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md

has been moved just yesterday to

https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md


I re-open the bug as it wasn't actually fixed. We've disabled the fuzzer, this is why CF cannot reproduce the issue anymore and marks it as fixed.

As for the fix, thanks for analysis in c#9. Is there any function like "InitializeEverythingWeNeed" we might call? :)

For more information, please see https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md.

The link referenced in the description is no longer valid.

(bulk edit)

It's still reproducible, need to decide whether we improve the fuzzer and fix this, or do we consider deleting the fuzzer at all.

 Issue 859354  has been merged into this issue.

 Issue 861609  has been merged into this issue.

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

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

It's still happegning. I'm going to merge one more issue to this one.

 Issue 910871  has been merged into this issue.

Issue 914719 has been merged into this issue.

 mmoroz@, what's the status?

Hm, I think we've disabled this particular fuzzer (c#12), but if the crash looks legit and is also detected by other fuzzers, we probably need to find a proper owner.

Yeah, I've re-opened issue 914719.


For this one, I'll see how is the fuzzer performing and either re-enable it or delete at all.