suspected cl :https://chromium.googlesource.com/chromium/src/+/d723c25e72442b9381023224d3db0ed12ae3210d%5E%21/base/metrics/histogram_base.cc

bcwhite@ could you please look into this. Thanks much

This is the second issue you've assigned to me for that CL which, as far as I can tell, has absolutely nothing to do with the assertion that failed.

Can you tell me how you tracked it to that CL?

I'm presently doing some work in the immediate neighborhood of this code, so I can take a look.

This is a case where we load a DocumentResource for an SVGUseElement, and before loading finishes, the base URL of the document is changed. So when we attempt to resolve the target element we will resolve the URL against the new base and get a different URL - which obviously doesn't match the URL from the DocumentResource which we are using (which is what the ASSERT is about.)

P1 seems a bit high for this.

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

commit 91e189ad391cd78854f71f816c08c08e7bc991a4
Author: fs <fs@opera.com>
Date: Fri Jul 22 10:55:59 2016

Resolve URL/target reference at a single point in SVGUseElement

The <base> URL can change between the attribute (href) is updated and
the shadow tree constructed. This causes confusion in the target
resolving code since it can produce different results at different
points in time.
Only resolve the URL on changes (to 'href'), extract the fragment
identifier and store whether the reference is local or not.
Refactor the SVGUseElement target element lookup with an eye to
future handling of "fragment-only" (local) URLs.
This makes the externalDocument in
SVGURIReference::targetElementFromIRIString unused, so remove that
codepath and simplify the function accordingly.

This changes behavior from resolving the URL and target element when
needed (depending on when layouts happen), to only when the 'href' is
mutated. This new behavior matches Edge, but not Gecko.

BUG= 601203 ,  470608 

Review-Url: https://codereview.chromium.org/2173453002
Cr-Commit-Position: refs/heads/master@{#407128}

[add] https://crrev.com/91e189ad391cd78854f71f816c08c08e7bc991a4/third_party/WebKit/LayoutTests/svg/custom/use-external-base-change-assert-expected.txt
[add] https://crrev.com/91e189ad391cd78854f71f816c08c08e7bc991a4/third_party/WebKit/LayoutTests/svg/custom/use-external-base-change-assert.html
[add] https://crrev.com/91e189ad391cd78854f71f816c08c08e7bc991a4/third_party/WebKit/LayoutTests/svg/custom/use-external-dynamic-base-change-expected.html
[add] https://crrev.com/91e189ad391cd78854f71f816c08c08e7bc991a4/third_party/WebKit/LayoutTests/svg/custom/use-external-dynamic-base-change.html
[modify] https://crrev.com/91e189ad391cd78854f71f816c08c08e7bc991a4/third_party/WebKit/Source/core/svg/SVGURIReference.cpp
[modify] https://crrev.com/91e189ad391cd78854f71f816c08c08e7bc991a4/third_party/WebKit/Source/core/svg/SVGURIReference.h
[modify] https://crrev.com/91e189ad391cd78854f71f816c08c08e7bc991a4/third_party/WebKit/Source/core/svg/SVGUseElement.cpp
[modify] https://crrev.com/91e189ad391cd78854f71f816c08c08e7bc991a4/third_party/WebKit/Source/core/svg/SVGUseElement.h

ClusterFuzz has detected this issue as fixed in range 406809:407197.

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

Fuzzer: inferno_twister
Job Type: linux_debug_content_shell_drt
Platform Id: linux

Crash Type: ASSERT
Crash Address: 
Crash State:
  equalIgnoringFragmentIdentifier(url, externalDocument->url())
  blink::SVGURIReference::targetElementFromIRIString
  blink::SVGUseElement::buildPendingResource
  
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_debug_content_shell_drt&range=406809:407197

Minimized Testcase (6.93 Kb): https://cluster-fuzz.appspot.com/download/AMIfv95iSPzlcn-tfuFLgw7pLyA-vke06p40psy93iKEr0HszVlKfbkAqEDuHMbk0pVAWUnRtwWyVt-CjT1zfa1bbTSbsxrrYv6YrploMFxCXGF1Ne1j15-par6g1NZ9Dew26sp1KGCbS9kBJyIu1IYQ18Sfl5_K7w?testcase_id=6516846114635776

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.

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