Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Automatically adding ccs based on OWNERS file / target commit history.

If this is incorrect, please add ClusterFuzz-Wrong label.

As per the  Issue 873567  owner assigning this issue to @mlamouri.
@mlamouri -- Could you please look into this issue.

Thanks.

ClusterFuzz has detected this issue as fixed in range 620999:621027.

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

Fuzzer: libFuzzer_media_pipeline_integration_fuzzer
Fuzz target binary: media_pipeline_integration_fuzzer
Job Type: x86_libfuzzer_chrome_asan_debug
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  false. Non-finite (i.e. NaN or positive/negative infinity) values cannot be repr
  base::Value::Value
  base::DictionaryValue::SetDouble
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=x86_libfuzzer_chrome_asan_debug&range=617968:617971
Fixed: https://clusterfuzz.com/revisions?job=x86_libfuzzer_chrome_asan_debug&range=620999:621027

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

See https://github.com/google/clusterfuzz-tools for instructions to reproduce this bug locally.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 4993108825341952 is verified as fixed, so closing issue as verified.

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

Hmm, this is not fixed, it just took time to hit the crash and there's now a default timeout in the runloop. See d9e4cb77324a3d4e0dfd6b599ce34e1224fdedb6 -- +wez, mmoroz

Re #6: You can add a ScopedRunTimeoutForTest(TimeDelta()) to disable the Run() timeout, if these tests actually need to run for a longer time in order to be useful?

Marking Assigned as per "this is not fixed" in #6.

Probably we should consume the timeout argument from the command line and use that as the test timeout instead of test_action() if I'm reading the CL comments correctly.

Max, is there a way to get the timeout value inside the fuzzer?

Yes, it's possible to define LLVMFuzzerInitialize function which would be called once on a startup and have access to argc/argv: https://llvm.org/docs/LibFuzzer.html

Just tested with the following:

extern "C" int LLVMFuzzerInitialize(int *argc, char ***argv) {
 printf("%d: %s\n", *argc, (*argv)[1]);
 return 0;
}


$ out/lfasan/zlib_uncompress_fuzzer -timeout=123
2: -timeout=123
INFO: Seed: 2898665770
<...>

Actually we think this is just a delayed "fixed" notification - I broke this fuzzer fixture (see  issue 920111 ) which is why these failures got closed-out. The fix for that has already landed, so things should be back to normal.

I'm a bit surprised ClusterFuzz assigned this to me. For what I can tell, it's an issue coming from MediaLog. The error is:
```
[1219/185811.482223:FATAL:values.cc(139)] Check failed: false. Non-finite (i.e. NaN or positive/negative infinity) values cannot be represented in JSON
```

Which came from:
```
    #8 0xf79be592 in base::DictionaryValue::SetDouble(base::BasicStringPiece<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, double) base/values.cc:797
    #9 0xf34251e2 in media::MediaLog::CreateTimeEvent(media::MediaLogEvent::Type, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, base::TimeDelta) media/base/media_log.cc:271:19
```

I have a quick fix that instead of predicting whether InSecondsF() will return a finite number, the code checks whether the returned value is a finite number. Hopefully, it will avoid the issue.

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

commit 698f2608e014afbc761673384d6a4459b6a9ee85
Author: Mounir Lamouri <mlamouri@chromium.org>
Date: Thu Jan 10 19:15:45 2019

Media Log: don't try to guess if time is finite, check end value instead.

Bug:  917024 
Change-Id: Ib53dad166a74784aba3cf3211167bda06581b3ea
Reviewed-on: https://chromium-review.googlesource.com/c/1404162
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Mounir Lamouri <mlamouri@chromium.org>
Cr-Commit-Position: refs/heads/master@{#621688}
[modify] https://crrev.com/698f2608e014afbc761673384d6a4459b6a9ee85/media/base/media_log.cc

ClusterFuzz has detected this issue as fixed in range 621658:621725.

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

Fuzzer: libFuzzer_media_pipeline_integration_fuzzer
Fuzz target binary: media_pipeline_integration_fuzzer
Job Type: x86_libfuzzer_chrome_asan_debug
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  false. Non-finite (i.e. NaN or positive/negative infinity) values cannot be repr
  base::Value::Value
  base::DictionaryValue::SetDouble
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=x86_libfuzzer_chrome_asan_debug&range=617968:617971
Fixed: https://clusterfuzz.com/revisions?job=x86_libfuzzer_chrome_asan_debug&range=621658:621725

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

See https://github.com/google/clusterfuzz-tools for instructions to reproduce this bug locally.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.