hitting assert runtime/vm/deferred_objects.cc: 112: error: expected: Thread::IsDeoptAfter(deopt_id_) || (code.GetPcForDeoptId(deopt_id_, RawPcDescriptors::kDeopt) != 0)

[a-siva]

Running the following test produces an assertion in debug mode and a crash in release mode

out/DebugX64/dart --preview-dart-2 --verbose-gc --collect-code --code-collection-interval-in-us=0 --old_gen_growth_rate=10 --log-code-drop --optimization-counter-threshold=-1 tests/standalone_2/io/code_collection_test.dart --run
produces a crash

../../runtime/vm/deferred_objects.cc: 112: error: expected: Thread::IsDeoptAfter(deopt_id_) || (code.GetPcForDeoptId(deopt_id_, RawPcDescriptors::kDeopt) != 0)
Dumping native stack trace for thread 23cd7
  [0x0000000000b4bbef] dart::Profiler::DumpStackTrace(void*)
  [0x0000000000b4bbef] dart::Profiler::DumpStackTrace(void*)
  [0x0000000000dd1c42] dart::Assert::Fail(char const*, ...)
  [0x00000000009c3a58] dart::DeferredRetAddr::Materialize(dart::DeoptContext*)
  [0x00000000009c6b20] dart::DeoptContext::MaterializeDeferredObjects()
  [0x0000000000bbadaa] dart::DRT_DeoptimizeMaterialize(dart::NativeArguments)
  [0x00007f1d31c808e7] [Stub] CallToRuntime
  [0x00007f1d31c8137b] [Stub] Deoptimize
  [0x0000000000000000] Unknown symbol
  [0x0000000000000000] Unknown symbol
  [0x0000000000000000] Unknown symbol
  [0x00007f1d2e86f90d] Utf8Decoder.convert
  [0x00007f1d2e508f53] BinaryBuilder.readStringEntry
  [0x00007f1d2e514353] BinaryBuilder.readStringTable
  [0x00007f1d2e512275] BinaryBuilder._readOneComponent
  [0x00007f1d2e51124f] BinaryBuilder.readComponent
  [0x00007f1d2b540311] IncrementalCompiler.prepareSummary
  [0x00007f1d2b566e62] IncrementalCompiler.computeDelta.<anonymous closure>

The test runs fine in Dart 1 mode.

[alexmarkov]

As '--optimization-counter-threshold=-1' option is specified, JIT assumes that no optimized code can run and no deoptimization can happen, so PC descriptors for deoptimization points are omitted:

sdk/runtime/vm/compiler/backend/flow_graph_compiler.cc

Lines 235 to 237 in a3c209d

	bool FlowGraphCompiler::CanOptimize() {
	return FLAG_optimization_counter_threshold >= 0;
	}

FlowGraphCompiler::AddDescriptor:

sdk/runtime/vm/compiler/backend/flow_graph_compiler.cc

Lines 634 to 635 in a3c209d

	// When running with optimizations disabled, don't emit deopt-descriptors.
	if (!CanOptimize() && (kind == RawPcDescriptors::kDeopt)) return;

However, there is an optimized code loaded from a snapshot. This code triggers deoptimization which looks for PC descriptor corresponding to a deoptimization point.

Do we use configuration '--optimization-counter-threshold=-1' anywhere besides testing?
Maybe we can remove this optimization from FlowGraphCompiler::AddDescriptor and emit PC descriptors even if --optimization-counter-threshold=-1. Does it make sense?

This optimization of PC descriptors was added in 5dd0bc5

/cc @rmacnak-google @a-siva @mraleph

[a-siva]

I believe we use it only for testing. I think always emitting the PC descriptors makes sense.