Unable to find the possible suspect using Predator, CL and Code Search.Hence untriaging this issue, Could some one please look into the issue.

Thank You.

This is the top crashes for that fuzzer, it happens in 100% of runs: https://clusterfuzz.com/v2/performance-report/libFuzzer_net_host_resolver_impl_fuzzer/libfuzzer_chrome_asan/2017-09-29

It's a blocker for fuzzer to discover new code areas and (potentially) find new bugs.

Linux testcase: https://clusterfuzz.com/v2/testcase-detail/5124735959826432

I haven't looked at this in detail yet, but based on the regression range and the fact that it's happening in a TaskScheduler task, it was likely caused by https://chromium-review.googlesource.com/637023 (migrating DNS lookups to TaskScheduler). I'm guessing it's a threading issue with FuzzedDataProvider which for some reason wasn't happening when we used WorkerPool. cc fdoray if you want to look at this, otherwise I'll get to it.

Since it would not be great to regress performance in the single-threaded case, how about a threadsafe wrapper for FuzzedDataProvider?

Does Clusterfuzz run tests under TSAN? If it's a race condition it should show up.

In my local build with DCHECKs, instead of the null dereference it crashes with [1003/174232.332049:FATAL:fuzzed_host_resolver.cc(82)] Check failed: network_task_runner_->BelongsToCurrentThread() just before it would have hit the null dereference. So the problem isn't related to the FuzzedDataProvider at all.

I see what's happening. FuzzedHostResolver used to create a HostResolverImpl with the current task runner supplied as the "worker pool task runnner", so everything used the same thread, but the CL linked in comment #4 removed the ability to do that, and FuzzedHostResolverProc isn't threadsafe.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e42adb2f814bbd91fdaa4d5f262001bf21c84d0c

commit e42adb2f814bbd91fdaa4d5f262001bf21c84d0c
Author: Miriam Gershenson <mgersh@chromium.org>
Date: Mon Oct 16 16:19:38 2017

Fix threading in HostResolverImpl fuzzer

The FuzzedHostResolverProc isn't threadsafe, so ProcTask needs to use a
sequenced TaskRunner when running in the context of the fuzzer. This
regressed during the migration away from WorkerPool.

Also remove an invalid DCHECK.

Bug:  769235 
Change-Id: I6802ecb3dd8506a74d04d4bd86fc3dacade3c66e
Reviewed-on: https://chromium-review.googlesource.com/710354
Commit-Queue: Miriam Gershenson <mgersh@chromium.org>
Reviewed-by: Matt Menke <mmenke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#509068}
[modify] https://crrev.com/e42adb2f814bbd91fdaa4d5f262001bf21c84d0c/ios/chrome/browser/ios_chrome_io_thread_unittest.mm
[modify] https://crrev.com/e42adb2f814bbd91fdaa4d5f262001bf21c84d0c/net/dns/fuzzed_host_resolver.cc
[modify] https://crrev.com/e42adb2f814bbd91fdaa4d5f262001bf21c84d0c/net/dns/host_resolver_impl.cc
[modify] https://crrev.com/e42adb2f814bbd91fdaa4d5f262001bf21c84d0c/net/dns/host_resolver_impl.h
[modify] https://crrev.com/e42adb2f814bbd91fdaa4d5f262001bf21c84d0c/net/dns/host_resolver_impl_fuzzer.cc

ClusterFuzz has detected this issue as fixed in range 509032:509158.

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

Fuzzer: libFuzzer_net_host_resolver_impl_fuzzer
Job Type: mac_libfuzzer_chrome_asan
Platform Id: mac

Crash Type: Null-dereference READ
Crash Address: 0x000000000008
Crash State:
  base::BasicStringPiece<std::__1::basic_string<char, std::__1::char_traits<char>,
  net::FuzzedHostResolverProc::Resolve
  net::HostResolverImpl::ProcTask::DoLookup
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=mac_libfuzzer_chrome_asan&range=504079:504126
Fixed: https://clusterfuzz.com/revisions?job=mac_libfuzzer_chrome_asan&range=509032:509158

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

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

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