Did this happen one off? Do you have any repro?

Context:
--------
We have a failsafe mechanism in the MemoryDumpManager that mutes a MDP if we fail to PostTask (which practically means that the underlying MessageLoop is gone) for 3 times in a row.
It's a protection against MDP forgetting to unregister themselves and wasting time on the dump.

Theory:
-------
Now, Given this is V8Isolate, I think that this was due to a worker that created an isolate on another thread. 

Which concretely means that very likely there is a bug somewhere that makes it so that the TaskRunner passed to the IsolateHolder goes away without destroying the IsolateHolder itself (otherwise the dtor of IsolateHolder would have unregistered the MDP)

+jochen: I am not familiar with the lifetime of IsolateHolder. Is it expected that tis taskrunner can suddenly become invalid while the IsolateHolder is still alive?

[mac bug triage] Needs feedback from reporter.

Repro steps: launch Chrome Canary on macOS. Navigate to some web pages. Wait.

there are two kind of isolate holders: the one for the main thread which never dies, and one per worker thread. They die some time during worker thread shutdown.

I don't know the expected lifetime of the taskrunner related to worker threads.

+nhiroki

-> ssid@ [mac triage] this doesn't belong in the triage queue.

Looks like this was added in r377632

Can we suppress the error, or WARN during shutdown so it's clear this is non-critical?

 Issue 774257  has been merged into this issue.

This is really spammy and I would like it to stop. In a Chrome instance I launched yesterday, I've received this message 53 times. It's the majority of the logging output. I haven't figured out the repro enough, but I will keep an eye on the terminal and see when it happens next.

Given this message has existed for a while, either I did not notice this whole time, or some recent change made it trigger more often.

> This is really spammy and I would like it to stop.

Yeah I didn't realize the extend of this until I saw that myself on the internal thread.
I'm going to turn this into a DLOG until we find and solve the root cause (seems pretty reproducible now).

Honestly I hate logs as well, but I don't know a way in the middle between CHECK (which is a strong hammer here for the user, but delivers actionable feedback) and LOG (where we just rely on people reporting cases like this).
If this was just a DLOG in the first place we would have never noticed about this and never tried to fix it.

And, yes, I know about DumpWithoutCrashing but that is too dangerous and invasive (causes jank, requires throttling)

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

commit 547f6f35f1a5b83adb8885bd070c281484d60d7d
Author: Primiano Tucci <primiano@chromium.org>
Date: Wed Oct 18 11:26:33 2017

memory-infra: turn LOG into DLOG for MDP PostTask failures

It is causing too much spam.

TBR=ssid

Bug: 762723
Change-Id: If4e57ff410d3dcef1c53192edc70536f51161618
Reviewed-on: https://chromium-review.googlesource.com/725383
Reviewed-by: Primiano Tucci <primiano@chromium.org>
Commit-Queue: Primiano Tucci <primiano@chromium.org>
Cr-Commit-Position: refs/heads/master@{#509742}
[modify] https://crrev.com/547f6f35f1a5b83adb8885bd070c281484d60d7d/base/trace_event/memory_dump_manager.cc

This is on my workstation, BTW. After comment 8, I didn't see any more yesterday. Left Chrome running overnight, checked just now, and there's ~15 more, with only 6 tabs + 3 extensions running. All my entries start with "[1:1:" so I'm guessing it's some sandboxed process.

ssid: ping

Sorry didn't realize this was assigned to me. I thought it was assigned to jochen.
I looked at the code, the registration happens when IsolateHolder is created and unregistered when destroyed. This error is only possible when the IsolateHolder is not destroyed before the thread, or we got the wrong thread.
Sent a cl for review to fix what looks like a problem:
https://chromium-review.googlesource.com/c/chromium/src/+/736045

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

commit 331b5f0d92a60529c7e64e3b51944cc77de5829b
Author: Siddhartha <ssid@chromium.org>
Date: Tue Dec 12 14:47:05 2017

V8 dump provider should be registered on isolate thread

The V8 dump provider is currently registered on the thread that
IsolateHolder is created on. The isolate should be accessed on the task
runner provided rather than the current thread.


Bug: 762723
Change-Id: I9674690362fc0287d21baa27428b5093cb5146a7
Reviewed-on: https://chromium-review.googlesource.com/736045
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Sami Kyöstilä <skyostil@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Siddhartha S <ssid@chromium.org>
Cr-Commit-Position: refs/heads/master@{#523429}
[modify] https://crrev.com/331b5f0d92a60529c7e64e3b51944cc77de5829b/gin/isolate_holder.cc
[modify] https://crrev.com/331b5f0d92a60529c7e64e3b51944cc77de5829b/gin/v8_isolate_memory_dump_provider.cc
[modify] https://crrev.com/331b5f0d92a60529c7e64e3b51944cc77de5829b/gin/v8_isolate_memory_dump_provider.h

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

commit 5ac59e663d764a3257c8a038a364d4cd578b4ef4
Author: Siddhartha <ssid@chromium.org>
Date: Wed Jan 03 09:02:07 2018

Make WebThread::GetSingleThreadTaskRunner virtual

gin/per_isolate_data expects task runner to be provided when
initializing isolate. Implementing GetWebTaskRunner seems unnecessary.
So, make WebThread::GetSingleThreadTaskRunner() virtual and implement it
in utility thread.

BUG=762723

Change-Id: Ib8aefb5ceca077166d361cc5be9396de170d9453
Reviewed-on: https://chromium-review.googlesource.com/819110
Commit-Queue: Siddhartha S <ssid@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#526653}
[modify] https://crrev.com/5ac59e663d764a3257c8a038a364d4cd578b4ef4/content/child/blink_platform_impl.cc
[modify] https://crrev.com/5ac59e663d764a3257c8a038a364d4cd578b4ef4/content/renderer/render_thread_impl.cc
[modify] https://crrev.com/5ac59e663d764a3257c8a038a364d4cd578b4ef4/third_party/WebKit/Source/bindings/core/v8/V8Initializer.cpp
[modify] https://crrev.com/5ac59e663d764a3257c8a038a364d4cd578b4ef4/third_party/WebKit/Source/platform/WebThread.cpp
[modify] https://crrev.com/5ac59e663d764a3257c8a038a364d4cd578b4ef4/third_party/WebKit/Source/platform/bindings/V8PerIsolateData.cpp
[modify] https://crrev.com/5ac59e663d764a3257c8a038a364d4cd578b4ef4/third_party/WebKit/Source/platform/bindings/V8PerIsolateData.h
[modify] https://crrev.com/5ac59e663d764a3257c8a038a364d4cd578b4ef4/third_party/WebKit/Source/platform/scheduler/child/webthread_base.cc
[modify] https://crrev.com/5ac59e663d764a3257c8a038a364d4cd578b4ef4/third_party/WebKit/Source/platform/scheduler/child/webthread_impl_for_worker_scheduler.cc
[modify] https://crrev.com/5ac59e663d764a3257c8a038a364d4cd578b4ef4/third_party/WebKit/Source/platform/scheduler/child/webthread_impl_for_worker_scheduler.h
[modify] https://crrev.com/5ac59e663d764a3257c8a038a364d4cd578b4ef4/third_party/WebKit/Source/platform/scheduler/child/webthread_impl_for_worker_scheduler_unittest.cc
[modify] https://crrev.com/5ac59e663d764a3257c8a038a364d4cd578b4ef4/third_party/WebKit/Source/platform/scheduler/renderer/webthread_impl_for_renderer_scheduler.cc
[modify] https://crrev.com/5ac59e663d764a3257c8a038a364d4cd578b4ef4/third_party/WebKit/Source/platform/scheduler/renderer/webthread_impl_for_renderer_scheduler.h
[modify] https://crrev.com/5ac59e663d764a3257c8a038a364d4cd578b4ef4/third_party/WebKit/Source/platform/scheduler/utility/webthread_impl_for_utility_thread.cc
[modify] https://crrev.com/5ac59e663d764a3257c8a038a364d4cd578b4ef4/third_party/WebKit/Source/platform/scheduler/utility/webthread_impl_for_utility_thread.h
[modify] https://crrev.com/5ac59e663d764a3257c8a038a364d4cd578b4ef4/third_party/WebKit/Source/platform/testing/TestingPlatformSupportWithMockScheduler.cpp
[modify] https://crrev.com/5ac59e663d764a3257c8a038a364d4cd578b4ef4/third_party/WebKit/public/platform/WebThread.h
[modify] https://crrev.com/5ac59e663d764a3257c8a038a364d4cd578b4ef4/third_party/WebKit/public/platform/scheduler/child/webthread_base.h
[modify] https://crrev.com/5ac59e663d764a3257c8a038a364d4cd578b4ef4/tools/v8_context_snapshot/v8_context_snapshot_generator.cc

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

commit 031fecd6f4b67c6f0c3ea3787a28a7d586658fad
Author: Siddhartha <ssid@chromium.org>
Date: Fri Jan 05 02:14:25 2018

Make sure V8PerIsolateData is initialized with a valid task runner

BUG=762723

Change-Id: Idcf189244d8abd8cda5eb48e32e001c5e9b9ef17
Reviewed-on: https://chromium-review.googlesource.com/818742
Commit-Queue: Siddhartha S <ssid@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#527189}
[modify] https://crrev.com/031fecd6f4b67c6f0c3ea3787a28a7d586658fad/gin/isolate_holder.cc
[modify] https://crrev.com/031fecd6f4b67c6f0c3ea3787a28a7d586658fad/gin/per_isolate_data.cc
[modify] https://crrev.com/031fecd6f4b67c6f0c3ea3787a28a7d586658fad/gin/public/isolate_holder.h
[modify] https://crrev.com/031fecd6f4b67c6f0c3ea3787a28a7d586658fad/third_party/WebKit/Source/platform/bindings/V8PerIsolateData.cpp
[modify] https://crrev.com/031fecd6f4b67c6f0c3ea3787a28a7d586658fad/tools/v8_context_snapshot/v8_context_snapshot_generator.cc