Unable to find the suspect through code search and also from the provided CL, hence adding appropriate label and leaving it as untriaged for further updates.

Thanks!

This may be a URL issuem either way, seems like we can restrict length.  Eric:  You want to take this, or should I?

This is not the same as  Issue 802258 .

I ran a profile, and and the problem is the sheer amount of proxy bypass rules being parsed (over 316,000).

The parsing of each individual rule isn't bad -- on average they are 1-2 characters long. However all the overheads of allocations, URL and hostname canonicalizations, repeated 316k times add up to a long runtime.

Restricting the length of input to the fuzzer SGTM; I can take a look.

Great, thanks!

Slight correction: we are parsing 633,264 rules (since the fuzzer parses twice).

With the coverage instrumentation, that comes out to an average time of 24 microseconds per rule, which isn't a concern given how this code is used.

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

commit b8522d6eac154f8916f6685eae5a0c2914a08fe7
Author: Eric Roman <eroman@chromium.org>
Date: Thu Mar 01 02:53:58 2018

Limit the size of input to parse_proxy_bypass_rules_fuzzer to 512 bytes.

Clusterfuzz is currently sending inputs in excess of 814 KB, which results in a correct but slow execution (times out).

Given the simple grammar of proxy bypass rules, 512 bytes is more than enough to explore it.

Bug:  813619 
Change-Id: I1415a1a15bb2996b6698b96b9cdef856a4988110
Reviewed-on: https://chromium-review.googlesource.com/942098
Reviewed-by: Matt Menke <mmenke@chromium.org>
Reviewed-by: Abhishek Arya <inferno@chromium.org>
Commit-Queue: Eric Roman <eroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#540004}
[modify] https://crrev.com/b8522d6eac154f8916f6685eae5a0c2914a08fe7/net/BUILD.gn
[modify] https://crrev.com/b8522d6eac154f8916f6685eae5a0c2914a08fe7/net/proxy_resolution/parse_proxy_bypass_rules_fuzzer.cc