Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/v8/v8/+/03364b6245a696c51b43e1c3186f0795168f6270 ([gn] Switch asan builders to gn).

If this is incorrect, please remove the owner and apply the Test-Predator-Wrong-CLs label.

Probably the switch of the bots to GN flushed out an existing problem.

I can reproduce this. It's a crash deep in the ICU library. Assigning adamk@, perhaps he can also find a better owner.

Somehow calendar's AMPM field has an invalid value of -49. Will keep looking. 

icu_59::Calendar::get (this=0x5555556253b0, field=UCAL_AM_PM, status=@0x7fffffffc90c: U_ZERO_ERROR)
    at ../../third_party/icu/source/i18n/calendar.cpp:1169
1169        if (U_SUCCESS(status)) ((Calendar*)this)->complete(status); // Cast away const
(gdb) n
1170        return U_SUCCESS(status) ? fFields[field] : 0;
(gdb) p status
$5 = (UErrorCode &) @0x7fffffffc90c: U_ZERO_ERROR
(gdb) p field  
$6 = UCAL_AM_PM
(gdb) p fFields
$7 = {0, 5877521, 2, 10, 1, 3, 63, 3, 1, -49, -8, -596, -31, -23, -648, -28378000, 0, -5877520, 3, -5877520, -2145043060, -2147483648, 0}

NaN is passed to ICU's DateFormat::format() from v8. 

    at ../../third_party/icu/source/i18n/datefmt.cpp:289
#5  0x00007ffff5e6e805 in icu_59::DateFormat::format (this=0x55555564a830, date=nan(0x8000000000000), appendTo=...)
    at ../../third_party/icu/source/i18n/datefmt.cpp:323
#6  0x00007ffff7855c89 in v8::internal::__RT_impl_Runtime_InternalDateFormat (args=..., isolate=0x55555559a150)
    at ../../src/runtime/runtime-intl.cc:273

hmm.... I added NUMBER_IS_NAN(dateMs) check to throw an range error, but NaN still reaches  Runtime_InternalDateFormat in runtime-intl.cc 

function formatDate(formatter, dateValue) {
  var dateMs;
  if (IS_UNDEFINED(dateValue)) {
    dateMs = %DateCurrentTime();
  } else {
    dateMs = TO_NUMBER(dateValue);
  }

  if (!NUMBER_IS_FINITE(dateMs)) throw %make_range_error(kDateRange);

  return %InternalDateFormat(formatter, new GlobalDate(dateMs));
}

* case A:

d8> (new Intl.DateTimeFormat("en-US", {hour: "numeric"})).format(new Date("ponies"))
(d8):1: RangeError: Provided date is not in valid range.
(new Intl.DateTimeFormat("en-US", {hour: "numeric"})).format(new Date("ponies"))
                                                      ^
RangeError: Provided date is not in valid range.
    at DateTimeFormat.fst (native)
    at (d8):1:5

* case B: 

d8> Date.prototype.valueOf = "ponies"
(new Intl.DateTimeFormat("en-US", {hour: "numeric"})).format()


#
# Fatal error in ../../src/runtime/runtime-intl.cc, line 283
# Check failed: std::isnormal(date_value) || date_value == 0.

-----------

case A is filtered in intl.js, but case B (this bug) is not. Hmm... so, do we need a 2nd line of defence in runtime-intl.cc ?  

intl.js has the following The check (NUMBER_IS_FINITE) does not help case B. So, I'll add a second check to runtime. In addition, I'll add a check for nan/infinity to ICU. 

function formatDate(formatter, dateValue) {
  var dateMs;
  if (IS_UNDEFINED(dateValue)) {
    dateMs = %DateCurrentTime();
  } else {
    dateMs = TO_NUMBER(dateValue);
  }

  if (!NUMBER_IS_FINITE(dateMs)) throw %make_range_error(kDateRange);

  return %InternalDateFormat(formatter, new GlobalDate(dateMs));
}

An ICU bug:  https://ssl.icu-project.org/trac/ticket/13430  (it's not necessary for fixing this bug because we can do the check on the v8's side .) 

https://cs.chromium.org/chromium/src/third_party/icu/source/i18n/smpdtfmt.cpp?rcl=21d33b1a09a77f033478ea4ffffb61e6970f83bd&l=1240 shows the next line repeats the check as tested in the assert, and does nothing if it fails.  So there is unlikely to be a security issue.  Keeping as low as an abundance of caution.

A v8 CL: https://chromium-review.googlesource.com/c/v8/v8/+/724860

re: comment 14 - yeah. thanks !

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/831bc233038e6f64152f9efff3d6729d5f41091e

commit 831bc233038e6f64152f9efff3d6729d5f41091e
Author: Jungshik Shin <jshin@chromium.org>
Date: Thu Oct 19 23:25:52 2017

Intl.DateTimeFormat: throw RangeError for non-finite input

intl.js throws an exception when datetime-value to format is
Infinity or NaN, but there was a way to thwart the check.

Moreover, intl.js and runtime-intl.cc have unnecessary conversions
of 'Number->Date->Number'. I removed the unnecessary conversion
and made 'Number' be passed to %InternalDateFormat.  With this
streamlining, the work-around mentioned above does not work
anymore.

Add a check in runtime_intl.cc for Infinity/NaN and throw a
RangeError.

Add invalid-time test for invalid datetime-values passed to
Intl.DateTimeFormat.format().

Bug:  chromium:774833 
Test: intl/date-format/invalid-time.js
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Idc575e532a86ee110dc4bb945ae023d6516650ee
Reviewed-on: https://chromium-review.googlesource.com/724860
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48765}
[modify] https://crrev.com/831bc233038e6f64152f9efff3d6729d5f41091e/src/js/intl.js
[modify] https://crrev.com/831bc233038e6f64152f9efff3d6729d5f41091e/src/runtime/runtime-intl.cc
[add] https://crrev.com/831bc233038e6f64152f9efff3d6729d5f41091e/test/intl/date-format/invalid-time.js

ClusterFuzz has detected this issue as fixed in range 48764:48765.

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

Fuzzer: ochang_js_fuzzer
Job Type: linux_asan_d8_dbg
Platform Id: linux

Crash Type: ASSERT
Crash Address: 
Crash State:
  0 <= value && value < symbolsCount
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_d8_dbg&range=39415:39416
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_d8_dbg&range=48764:48765

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

See https://github.com/google/clusterfuzz-tools 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 6718920999567360 is verified as fixed, so closing issue as verified.

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

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot