Assigning to concern owner from Predator results --
The result is a list of CLs that change the crashed files. 

Author: shivanisha
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/8061c420676998bda77caa74581ea8061860f438
Time: Tue Jun 13 23:35:52 2017
Lines 2759 of file http_cache_transaction.cc which potentially caused crash are changed in this cl (frame #5, "net::HttpCache::Transaction::WriteResponseInfoToEntry").
Minimum distance from crash line to modified line: 0. (file: http_cache_transaction.cc, crashed on: 2759, modified: 2759).

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

The dcheck that is getting hit is checking the expected response code to be 200 while the test case is sending an invalid response code of 2. http_cache_transaction.cc has many such checks on the response code for a long time. Is this a new test case? Not sure why is it failing only now.

[0714/000748.106895:FATAL:http_cache_transaction.cc(2816)] Check failed: 200 == response_.headers->response_code() (200 vs. 2)

The regression range [1] is tight enough that I would suspect one of the CLs there to be the culprit. If you suspect it is wrong you could try to repro from somewhere before that range.

Did your CL change truncation logic? It's possible before we wouldn't truncate the response before we've received the full response code, or something like that.

[1]: https://chromium.googlesource.com/chromium/src/+log/e6e5aae826b354d44a155460d6a2e0674971f4c8..78764cfda4e4ec4be86bd7a56d7cb7e053692b01?pretty=fuller

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

commit e171138dc1f2fa05e01114518f9d7d852d90f66a
Author: Shivani Sharma <shivanisha@chromium.org>
Date: Mon Jul 24 15:50:15 2017

Do not attempt truncation if the response headers or code sent by the server is garbled.
This CL brings back the checks that were earlier there and were removed in CL 
https://codereview.chromium.org/2721933002

Bug:  739112 
Change-Id: Iaefa890dec748e141aafcbe558708668a543e9bf
Reviewed-on: https://chromium-review.googlesource.com/575867
Reviewed-by: Josh Karlin <jkarlin@chromium.org>
Commit-Queue: Shivani Sharma <shivanisha@chromium.org>
Cr-Commit-Position: refs/heads/master@{#488980}
[modify] https://crrev.com/e171138dc1f2fa05e01114518f9d7d852d90f66a/net/http/http_cache.cc
[modify] https://crrev.com/e171138dc1f2fa05e01114518f9d7d852d90f66a/net/http/http_cache.h
[modify] https://crrev.com/e171138dc1f2fa05e01114518f9d7d852d90f66a/net/http/http_cache_unittest.cc

ClusterFuzz has detected this issue as fixed in range 488978:489060.

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

Fuzzer: libFuzzer_net_url_request_fuzzer
Job Type: libfuzzer_chrome_asan_debug
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  200 == response_.headers->response_code() in http_cache_transaction.cc
  base::debug::DebugBreak
  net::HttpCache::Transaction::WriteResponseInfoToEntry
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=479187:479277
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=488978:489060

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


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

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