Users experienced this crash on the following builds:

Win Canary 57.0.2961.0 -  1328.10 CPM, 20862 reports, 11521 clients (signature base::ThreadTaskRunnerHandle::Get)
Mac Canary 57.0.2961.0 -  2896.62 CPM, 4662 reports, 3044 clients (signature base::ThreadTaskRunnerHandle::Get)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

users are talking about this on reddit too - https://pay.reddit.com/r/chrome/comments/5k7zpq/help_0xc0000005_error_every_5_minutes/

please revert CL as soon as possible, I'll probably go ahead and start reverting ThreadTaskRunner CLs soon. Merry Christmas.

 Issue 676898  has been merged into this issue.

the initial triage was correct - I am going ahead and reverting https://codereview.chromium.org/2566053002 to fix Canary for a happy noel. 

Issue 676962 has been merged into this issue.

 Issue 676961  has been merged into this issue.

The crashing is actually a christmass easter egg ???

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

commit 53919401199f8cc8c0e5042dd9c0fc9716825a1c
Author: wfh <wfh@chromium.org>
Date: Sun Dec 25 21:30:26 2016

Revert of Convert utility process out-of-process file patching to mojo (patchset #15 id:420001 of https://codereview.chromium.org/2566053002/ )

Reason for revert:
broke component updater - see  crbug.com/676960 

Original issue's description:
> Convert utility process out-of-process file patching to mojo
>
> Define interface chrome::mojom::FilePatcher for out-of-process file
> patching. Add that interface to the utility process, and expose the
> interface to the browser process by mojo policy [1].
>
> ChromeOutOfProcessPatcher: remove PatchHost() helper class, replace
> it with a content::UtilityProcessMojoClient() and use that to start
> and stop the utility process needed for out-of-process file patches
> and to perform out-of-process file patches using mojo calls, rather
> than IPC::Send().
>
> Add a in-process browser test for the ChromeOutOfProcessPatcher (it
> had no tests http://bit.ly/2h8mafX it seems). Copy the golden files
> to random locations (input_file, patch_file) and patch them: checks
> the patched output_file matches the golden output file.
>
> Delete all the IPC related to out-of-process file patching since we
> no longer use them, we use chrome::mojom::FilePatcher instead.
>
> [1] chrome_content_utility_manifest_overlay.json
>
> TBR=waffles@chromium.org
> BUG= 597124 ,  660325 
>
> Committed: https://crrev.com/32afc44b332255130c247e3bfc4a27261d11ddfb
> Cr-Commit-Position: refs/heads/master@{#440601}

TBR=jochen@chromium.org,dcheng@chromium.org,sammc@chromium.org,tibell@chromium.org,waffles@chromium.org,sorin@chromium.org,noel@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 597124 ,  660325 , 676960 

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

[modify] https://crrev.com/53919401199f8cc8c0e5042dd9c0fc9716825a1c/chrome/browser/chrome_content_utility_manifest_overlay.json
[modify] https://crrev.com/53919401199f8cc8c0e5042dd9c0fc9716825a1c/chrome/browser/component_updater/component_patcher_operation_out_of_process.cc
[modify] https://crrev.com/53919401199f8cc8c0e5042dd9c0fc9716825a1c/chrome/browser/component_updater/component_patcher_operation_out_of_process.h
[delete] https://crrev.com/79c889974fa1506fa36408f2bf4538f4a7ca70cf/chrome/browser/component_updater/component_patcher_operation_out_of_process_browsertest.cc
[modify] https://crrev.com/53919401199f8cc8c0e5042dd9c0fc9716825a1c/chrome/common/BUILD.gn
[modify] https://crrev.com/53919401199f8cc8c0e5042dd9c0fc9716825a1c/chrome/common/chrome_utility_messages.h
[delete] https://crrev.com/79c889974fa1506fa36408f2bf4538f4a7ca70cf/chrome/common/file_patcher.mojom
[modify] https://crrev.com/53919401199f8cc8c0e5042dd9c0fc9716825a1c/chrome/test/BUILD.gn
[modify] https://crrev.com/53919401199f8cc8c0e5042dd9c0fc9716825a1c/chrome/utility/chrome_content_utility_client.cc

Is update 57.0.2962.0 the update that fixes the bug?

Here's new "Signed Tree Heads" to bypass the crashing.

Deleted: 253.zip 7.8 KB

253.zip 7.8 KB Download

Thanks again rra already reinstalled normal chrome to get my own source.
but nice of you to share yours :D

Experiencing the similar crashes after updating to Canary 57.0.2962.0, on Windows 10, 64-bit.

Experiencing the similar crashes after updating to Canary 57.0.2962.0 on Windows 10, 64-bit.

Issue 676991 has been merged into this issue.

Issue 676986 has been merged into this issue.

Issue 676973 has been merged into this issue.

Issue 676971 has been merged into this issue.

 Issue 676959  has been merged into this issue.

Issue 676947 has been merged into this issue.

Issue 676946 has been merged into this issue.

Issue 676945 has been merged into this issue.

Issue 676938 has been merged into this issue.

Issue 676932 has been merged into this issue.

Issue 676929 has been merged into this issue.

Issue 676928 has been merged into this issue.

Issue 676927 has been merged into this issue.

Issue 676922 has been merged into this issue.

Issue 676899 has been merged into this issue.

 Issue 676833  has been merged into this issue.

Revert is successful and no crashes on the latest canary(57.0.2963.0) of Windows and Mac observed so far. 

I removed the Head Tree folder to allow for a component update of it and it didn't crash when I checked update on Windows, thanks for the quick fix.

+task scheduler owners
Is there high level documentation of how the base/task_scheduler interfaces work/example usage? I guess this is crashing because we never set the TTTH, but naively, I would have expected this to work.

IIUC the core issue here is that it's not possible to use ThreadTaskRunnerHandle::Get from the blocking pool, because there is no SingleThreadTaskRunner associated with an individual blocking pool thread. So sounds like we cannot start mojo services from the blocking pool?

In the component updater we run almost everything on either the UI thread (via a SingleThreadTaskRunner fetched from ThreadTaskRunnerHandle::Get) or via a SequencedTaskRunner which in practice represents tasks in the blocking pool.

I see, so this code should be using SequencedTaskRunnerHandle instead of ThreadTaskRunnerHandle.

(This doesn't change my request for more documentation though =)

#35 "So sounds like we cannot start mojo services from the blocking pool?"

Yes, it seems we cannot.  sammc@ looked at the current issue over the holiday  break and had the same conclusion: that mojo bindings do not work on the blocking pool currently.

"or via a SequencedTaskRunner which in practice represents tasks in the blocking pool"

Yeap + thanks for these details:  Block'n pool and mojo don't play well at this time, so we'll need to fix that first, before we try to mojo the file patcher IPC again ...

Right, we're looking to "sequencify" core APIs (base, a few components, pieces of net/, and mojo).

By this we mean, make them usable from a sequence. Most impls aren't truly thread-affine, they're merely thread-unsafe (but a sequence provides thread-safety so that's okay).

Pretty much any impl that doesn't use TLS should use SequenceChecker instead of ThreadChecker/manual PlatformThreadId checking (and SequencedTaskRunnerHandle instead of ThreadTaskRunnerHandle, etc.).

In order for this to work, it needs to be the case all the way down the stack, hence we're taking the task on ourselves to update the leaf/core APIs.

@dcheng: happy to document this, what is unclear in the current API you think and where would you expect to find such documentation?

@gab: our documentation is pretty scattered, but one place might be https://www.chromium.org/developers/coding-style/important-abstractions-and-data-structures#TOC-TaskRunner-SequencedTaskRunner-SingleThreadTaskRunner? All the info in there is still largely thread-oriented rather than sequence-oriented. There's also https://www.chromium.org/developers/design-documents/threading, etc.

(For me, I learned that that we have a new thing called SequencedTaskRunnerHandle, since the prevailing idiom is ThreadTaskRunnerHandle. It makes sense... but it's also relatively unknown, I feel.)

Right, we plan to update all the ThreadChecker/ThreadTaskRunnerHandle/etc headers with a comment stating that this is "probably not what you want". But we thought we should finish sequencification of the core APIs first ( issue 675631  -- otherwise anyone using those has to play by the old rules anyways).

I'll look into updating the docs on chromium.org.