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 assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/2a7c3b2cd5c6ad903ae422d5e6ce45a123ab92ac (Group experimental canvas features with the rest of web platform features).

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label. If you aren't the correct owner for this issue, please unassign yourself as soon as possible so it can be re-triaged.

Looking at the clusterfuzz report, the error might be flaky and not caused by the regression range as indicated. 

I saw that the error trace and minimized test case all come from File reader. mek@: could you take a look at this as some of your CLs recently touched the FileReader::FireEvent?

I don't think anything was changed recently that would effect this.

So if I understand the CHECK that is failing here, the problem is that FileReader::ContextDestroyed can sometimes cause events to be triggered?

In this particular case because we have many FileReaders trying to load in parallel, we're not actually starting all of them at the same time. But as the earlier ones are cancelled because they get their ContextDestroyed callback, later ones (that haven't gotten their ContextDestroyed callback yet) are getting told to start. And those later ones then want to send loadstart and/or loadend/error events, even though the context is already being destroyed.


Probably the right fix would be to teach FileReader::ThrottlingController to not start new readers if the context is (being) destroyed?

What makes this harder to reproduce is that the only way a FileReader can fail synchronously is if creating the mojo datapipe fails. So to reproduce the issue you need to eventually get FileReader to start failing in that way (but not immediately, because if all of them would fail that way we'd never get any pending file readers because they would all just fail right away).

Anyway, checking IsContextDestroyed() before starting new readers seems to do the trick.

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

commit 252a9d0265828f9422f23864095796612dd92220
Author: Marijn Kruisselbrink <mek@chromium.org>
Date: Wed Apr 25 20:40:30 2018

[FileAPI] Don't start FileReaders on a context that is destroyed.

The FileReaders themselves will abort once they realize the context is
destroyed anyway, so it is pretty pointless (and potentially
problematic) to start new FileReaders after the context is destroyed.

Bug:  836724 
Change-Id: I7bcbdf7d7905448df794df423a3fb0fe1697dd95
Reviewed-on: https://chromium-review.googlesource.com/1028555
Commit-Queue: Daniel Murphy <dmurph@chromium.org>
Reviewed-by: Daniel Murphy <dmurph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#553726}
[modify] https://crrev.com/252a9d0265828f9422f23864095796612dd92220/third_party/blink/renderer/core/fileapi/file_reader.cc

ClusterFuzz has detected this issue as fixed in range 553725:553727.

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

Fuzzer: inferno_layout_test_unmodified
Job Type: windows_asan_chrome_no_sandbox
Platform Id: windows

Crash Type: CHECK failure
Crash Address: 
Crash State:
  !context->IsIteratingOverObservers() in v8_script_runner.cc
  blink::V8ScriptRunner::CallFunction
  blink::V8EventListener::CallListenerFunction
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=windows_asan_chrome_no_sandbox&range=543353:543374
Fixed: https://clusterfuzz.com/revisions?job=windows_asan_chrome_no_sandbox&range=553725:553727

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

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 6059324200452096 is verified as fixed, so closing issue as verified.

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