suspected cl :
https://chromium.googlesource.com/chromium/src/+/7dc7c0fc073b84f3050726b52ceec1bbcb304ba3%5E%21/third_party/WebKit/Source/wtf/text/StringToNumber.cpp

esprehn@ could you please look into this. Thanks 

That patch just moves the code around, I didn't change anything. Also this fuzzer is really bad, why is it truncating the call stacks?

The real stack in the CF dashboard is:

../../third_party/WebKit/Source/wtf/dtoa/strtod.cc:271:15: runtime error: shift exponent 44 is too large for 32-bit type int
    #0 0x7f09f25ba065 in DiyFpStrtod third_party/WebKit/Source/wtf/dtoa/strtod.cc:271:15
    #1 0x7f09f25ba065 in WTF::double_conversion::Strtod(WTF::double_conversion::Vector<char const>, int) third_party/WebKit/Source/wtf/dtoa/strtod.cc:437
    #2 0x7f09f25b5b5e in WTF::double_conversion::StringToDoubleConverter::StringToDouble(char const*, unsigned long, unsigned long*) third_party/WebKit/Source/wtf/dtoa/double-conversion.cc:596:28
    #3 0x7f09f25ccce2 in parseDouble third_party/WebKit/Source/wtf/dtoa.h:48:12
    #4 0x7f09f25ccce2 in double WTF::toDoubleType<unsigned char, (WTF::TrailingJunkPolicy)0>(unsigned char const*, unsigned long, bool*, unsigned long&) third_party/WebKit/Source/wtf/text/StringToNumber.cpp:217
    #5 0x7f09f25ccc50 in WTF::charactersToDouble(unsigned char const*, unsigned long, bool*) third_party/WebKit/Source/wtf/text/StringToNumber.cpp:233:12
    #6 0x7f09f4a4dcf0 in bool blink::parseTransformNumberArguments<unsigned char const>(unsigned char const*&, unsigned char const*, unsigned int, blink::CSSFunctionValue*) third_party/WebKit/Source/core/css/parser/CSSParserFastPaths.cpp:901:25
    #7 0x7f09f4a4d5a6 in parseSimpleTransformValue<const unsigned char> third_party/WebKit/Source/core/css/parser/CSSParserFastPaths.cpp:988:14
    #8 0x7f09f4a4d5a6 in parseSimpleTransformList<unsigned char> third_party/WebKit/Source/core/css/parser/CSSParserFastPaths.cpp:1056
    #9 0x7f09f4a4d5a6 in parseSimpleTransform third_party/WebKit/Source/core/css/parser/CSSParserFastPaths.cpp:1073
    #10 0x7f09f4a4d5a6 in blink::CSSParserFastPaths::maybeParseValue(blink::CSSPropertyID, WTF::String const&, blink::CSSParserMode) third_party/WebKit/Source/core/css/parser/CSSParserFastPaths.cpp:1085
    #11 0x7f09f4a4a682 in blink::CSSParser::parseValue(blink::MutableStylePropertySet*, blink::CSSPropertyID, WTF::String const&, bool, blink::StyleSheetContents*) third_party/WebKit/Source/core/css/parser/CSSParser.cpp:68:23
    #12 0x7f09f4a1fee8 in blink::MutableStylePropertySet::setProperty(blink::CSSPropertyID, WTF::String const&, bool, blink::StyleSheetContents*) third_party/WebKit/Source/core/css/StylePropertySet.cpp:302:12
    #13 0x7f09f49f7010 in blink::AbstractPropertySetCSSStyleDeclaration::setPropertyInternal(blink::CSSPropertyID, WTF::String const&, WTF::String const&, bool, blink::ExceptionState&) third_party/WebKit/Source/core/css/PropertySetCSSStyleDeclaration.cpp:302:33


and the test is doing:

  property: 'transform'}, [
  { is: 'matrix3d(2, 0, 0, 18446744073709551472, 0, 1.22465e-16, 9223372036854775688, 9223372036854775797, 6.12323e-170, 6.12323e-171, 6.12323e-17, 6.12323e-172, 6.12323e-173, 6.12323e-174, 6.12323e-175, 6.12323e-176)'}]);

So I guess this is a bug in the Strtod logic we're using to parse the ints? This code is super ancient, I'm not sure it's worth fixing these bugs, all the browsers overflow and do crazy stuff with huge numbers and it doesn't really impact web pages.

Base uses a variant of the same strtod parser. Note that parsing doubles is something we need to be really fast at, so a performance hit to avoid the undefined value here is sad. This code we use is just code from v8 copied into blink (base's version is also the v8 code). How did v8 fix this?

v8 fixed it by changing 'error' from an int to an int64_t: https://cs.chromium.org/chromium/src/v8/src/strtod.cc?l=249.

I see, we should just do the same thing. I'd really really like to get the parser in v8 moved into a third_party dep that base, v8 and blink could all depend on too. Having 3 copies of this code is bad, I'm not sure anyone really understands how the code as diverged over time.

Oh I'm wrong, the one in base is a different thing, which I think blink/webkit used a hacked up version of once:

https://cs.chromium.org/chromium/src/base/third_party/dmg_fp/dmg_fp.h?rcl=1470626560

 Issue 635418  has been merged into this issue.

dmg_fp should just die anyway, see bug 593512 and bug 95729 for two possible replacement ideas.

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

commit d74c8d750deee3b9412b978b1dc49e2d3f0d75d6
Author: esprehn <esprehn@chromium.org>
Date: Sat Oct 22 04:47:30 2016

Fix undefined shift in DiyFpStrtod.

This code is just copy pasta from v8, this patch copies a newer version
of the pasta.

https://chromium.googlesource.com/v8/v8/+/374a4da83e6f4e05d31640b23b5ca92f0bbf0586/src/strtod.cc#249

BUG= 637044 ,  629034 

Review-Url: https://chromiumcodereview.appspot.com/2438383003
Cr-Commit-Position: refs/heads/master@{#426973}

[modify] https://crrev.com/d74c8d750deee3b9412b978b1dc49e2d3f0d75d6/third_party/WebKit/Source/wtf/dtoa/strtod.cc

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