Clemens, mind taking a look please?

Aseem's going to take this one.

I can repro this, it looks like a dcheck failure at https://cs.chromium.org/chromium/src/v8/src/inspector/v8-debugger-script.cc?rcl=4468a936c7b92e7839ee4c5f22c3bff65de7fe6c&l=98. Here's the interesting part of my stack trace, from Linux:


#
# Fatal error in ../../v8/src/inspector/v8-debugger-script.cc, line 98
# Debug check failed: expectedV8ScriptId.utf8() == translatedScriptId.utf8() (28 vs. 28-14).
#
#
#
#FailureMessage Object: 0x7fffd05d7860#0 0x7fc9e7e559cd base::debug::StackTrace::StackTrace()
#1 0x7fc9e7b5d85a base::debug::StackTrace::StackTrace()
#2 0x7fc9ccd600a7 gin::(anonymous namespace)::PrintStackTrace()
#3 0x7fc9b322ca58 V8_Fatal()
#4 0x7fc9b322c47c v8::base::(anonymous namespace)::DefaultDcheckHandler()
#5 0x7fc9b322cb32 V8_Dcheck()
#6 0x7fc9cc652772 v8_inspector::(anonymous namespace)::TranslateProtocolLocationToV8Location()
#7 0x7fc9cc651ffa v8_inspector::(anonymous namespace)::WasmVirtualScript::getPossibleBreakpoints()
#8 0x7fc9cc6399c5 v8_inspector::V8DebuggerAgentImpl::getPossibleBreakpoints()
#9 0x7fc9cc5588ef v8_inspector::protocol::Debugger::DispatcherImpl::getPossibleBreakpoints()
#10 0x7fc9cc555629 v8_inspector::protocol::Debugger::DispatcherImpl::dispatch()
#11 0x7fc9cc51fe2f v8_inspector::protocol::UberDispatcher::dispatch()
#12 0x7fc9cc6a4cc1 v8_inspector::V8InspectorSessionImpl::dispatchProtocolMessage()
#13 0x7fc9c8d1220b blink::InspectorSession::DispatchProtocolMessage()
#14 0x7fc9c8bf4cee blink::DevToolsAgent::Session::DispatchProtocolCommand()
#15 0x7fc9c6246484 blink::mojom::blink::DevToolsSessionStubDispatch::Accept()
#16 0x7fc9c8bf6483 blink::mojom::blink::DevToolsSessionStub<>::Accept()
#17 0x7fc9e8096e53 mojo::InterfaceEndpointClient::HandleValidatedMessage()
#18 0x7fc9e80958a1 mojo::InterfaceEndpointClient::HandleIncomingMessageThunk::Accept()
#19 0x7fc9e8093d32 mojo::FilterChain::Accept()

I have seen this before. This happens if the information about virtual wasm scripts is accidentally reset via {WasmTranslation::Clear()}, called from {V8InspectorImpl::resetContextGroup} when a navigation or page reload happens.
Maybe it gets called spuriously?

So we are getting multiple different errors in various configurations. One of the errors I am seeing with source maps is as follows:
Anyone has any ideas what this could be related to?

[67742:775:1012/113031.860656:FATAL:queueing_time_estimator.cc(42)] Check failed: task_start <= task_end (297931169562 bogo-microseconds vs. 297928044752 bogo-microseconds)
0   libbase.dylib                       0x0000000127d015de base::debug::StackTrace::StackTrace(unsigned long) + 174
1   libbase.dylib                       0x0000000127d0169d base::debug::StackTrace::StackTrace(unsigned long) + 29
2   libbase.dylib                       0x00000001278d27ba base::debug::StackTrace::StackTrace() + 26
3   libbase.dylib                       0x000000012794083d logging::LogMessage::~LogMessage() + 461
4   libbase.dylib                       0x000000012793e3d5 logging::LogMessage::~LogMessage() + 21
5   libblink_platform.dylib             0x00000001626b68a7 blink::scheduler::(anonymous namespace)::ExpectedQueueingTimeFromTask(base::TimeTicks, base::TimeTicks, base::TimeTicks, base::TimeTicks) + 199
6   libblink_platform.dylib             0x00000001626b627b blink::scheduler::QueueingTimeEstimator::AdvanceTime(base::TimeTicks) + 779
7   libblink_platform.dylib             0x00000001626b645a blink::scheduler::QueueingTimeEstimator::OnExecutionStopped(base::TimeTicks) + 218
8   libblink_platform.dylib             0x00000001626944ed blink::scheduler::MainThreadSchedulerImpl::OnTaskCompleted(blink::scheduler::MainThreadTaskQueue*, base::sequence_manager::Task const&, base::sequence_manager::TaskQueue::TaskTiming const&) + 1437
9   libblink_platform.dylib             0x00000001626aa495 blink::scheduler::MainThreadTaskQueue::OnTaskCompleted(base::sequence_manager::Task const&, base::sequence_manager::TaskQueue::TaskTiming const&) + 69
10  libblink_platform.dylib             0x00000001626ab12d void base::internal::FunctorTraits<void (blink::scheduler::MainThreadTaskQueue::*)(base::sequence_manager::Task const&, base::sequence_manager::TaskQueue::TaskTiming const&), void>::Invoke<void (blink::scheduler::MainThreadTaskQueue::*)(base::sequence_manager::Task const&, base::sequence_manager::TaskQueue::TaskTiming const&), blink::scheduler::MainThreadTaskQueue*, base::sequence_manager::Task const&, base::sequence_manager::TaskQueue::TaskTiming const&>(void (blink::scheduler::MainThreadTaskQueue::*)(base::sequence_manager::Task const&, base::sequence_manager::TaskQueue::TaskTiming const&), blink::scheduler::MainThreadTaskQueue*&&, base::sequence_manager::Task const&&&, base::sequence_manager::TaskQueue::TaskTiming const&&&) + 157
11  libblink_platform.dylib             0x00000001626ab05a void base::internal::InvokeHelper<false, void>::MakeItSo<void (blink::scheduler::MainThreadTaskQueue::* const&)(base::sequence_manager::Task const&, base::sequence_manager::TaskQueue::TaskTiming const&), blink::scheduler::MainThreadTaskQueue*, base::sequence_manager::Task const&, base::sequence_manager::TaskQueue::TaskTiming const&>(void (blink::scheduler::MainThreadTaskQueue::* const&&&)(base::sequence_manager::Task const&, base::sequence_manager::TaskQueue::TaskTiming const&), blink::scheduler::MainThreadTaskQueue*&&, base::sequence_manager::Task const&&&, base::sequence_manager::TaskQueue::TaskTiming const&&&) + 122
...

That looks unrelated to wasm debugging (a task that takes -3.1 seconds to execute). Do you have a reproducer?

Adding Scheduling component for help on triaging.

The error can be reproduced by following the steps listed above and using test-without-source-maps

Adding tdresser, who it looks like added this DCHECK in the first place. Tim, any thoughts on why we'd see a DCHECK failure as in #c5?

That DCHECK is just making sure that the scheduler is giving us sane data - no clue why we'd be seeing wasm modules causing issues here.

+altimin@, who works on scheduling.

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

commit 2e6f4329a2af1d8b76a58d21e10fdc2c72655a66
Author: Aseem Garg <aseemgarg@chromium.org>
Date: Tue Nov 06 22:27:17 2018

[wasm] fix clear context group for wasm

This CL only clears the wasm translations that correspond to the context
group being reset instead of clearing all.

R=clemensh@chromium.org,kozyatinskiy@chromium.org
BUG=chromium:892864

Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ib5af0489cbdb7c9b1571cb9cf935fda3bee14015
Reviewed-on: https://chromium-review.googlesource.com/c/1292676
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57302}
[modify] https://crrev.com/2e6f4329a2af1d8b76a58d21e10fdc2c72655a66/src/inspector/v8-inspector-impl.cc
[modify] https://crrev.com/2e6f4329a2af1d8b76a58d21e10fdc2c72655a66/src/inspector/wasm-translation.cc
[modify] https://crrev.com/2e6f4329a2af1d8b76a58d21e10fdc2c72655a66/src/inspector/wasm-translation.h
[add] https://crrev.com/2e6f4329a2af1d8b76a58d21e10fdc2c72655a66/test/inspector/debugger/wasm-reset-context-group-expected.txt
[add] https://crrev.com/2e6f4329a2af1d8b76a58d21e10fdc2c72655a66/test/inspector/debugger/wasm-reset-context-group.js
[modify] https://crrev.com/2e6f4329a2af1d8b76a58d21e10fdc2c72655a66/test/inspector/inspector-test.cc
[modify] https://crrev.com/2e6f4329a2af1d8b76a58d21e10fdc2c72655a66/test/inspector/isolate-data.cc
[modify] https://crrev.com/2e6f4329a2af1d8b76a58d21e10fdc2c72655a66/test/inspector/isolate-data.h
[modify] https://crrev.com/2e6f4329a2af1d8b76a58d21e10fdc2c72655a66/test/inspector/protocol-test.js

I fixed the issue with clear. Now we only have the scheduler issue (both with and without source maps). 
Assigning to altimin@. Please, re-assign appropriately if needed..