vm crash in 1.24-dev-0.0+ triggered by something in dartdoc

[jcollins-g]

Working on a change for dartdoc in this branch: https://github.com/dart-lang/dartdoc/tree/warnings-update

I have encountered a crash in the dart VM, as demoed by Travis: https://travis-ci.org/dart-lang/dartdoc/jobs/231722764

and locally (with some debug prints to show what dartdoc was writing at the time of the crash):

/tmp/sdkdocs/dart-html/DomMatrix/m33.html
Dumping native stack trace for thread 11891
/tmp/sdkdocs/dart-html/DomMatrix/m34.html
/tmp/sdkdocs/dart-html/DomMatrix/m41.html
./tmp/sdkdocs/dart-html/DomMatrix/m42.html
/tmp/sdkdocs/dart-html/DomMatrix/m43.html
  [0x00000000008e130a] dart::Assembler::j(dart::Condition, dart::Label*, bool)
  [0x00000000008e130a] dart::Assembler::j(dart::Condition, dart::Label*, bool)
  [0x00000000009baf34] dart::BinarySmiOpInstr::EmitNativeCode(dart::FlowGraphCompiler*)
  [0x0000000000962729] dart::FlowGraphCompiler::VisitBlocks()
  [0x000000000096e0f5] dart::FlowGraphCompiler::CompileGraph()
  [0x00000000008bd7fc] dart::CompileParsedFunctionHelper::Compile(dart::CompilationPipeline*)
  [0x00000000008be3c6] Unknown symbol
  [0x00000000008bf2a6] dart::Compiler::CompileOptimizedFunction(dart::Thread*, dart::Function const&, long)
  [0x00000000008c0cc6] dart::BackgroundCompiler::Run()
  [0x0000000000bf28bd] dart::ThreadPool::Worker::Loop()
  [0x0000000000bf276a] dart::ThreadPool::Worker::Main(unsigned long)
  [0x0000000000aaa8e9] Unknown symbol
-- End of DumpStackTrace

Process finished with exit code 134 (interrupted by signal 6: SIGABRT)

Running the same code with 1.23 works fine, and working without the change in the warnings-update branch works fine -- however, dartdoc's SDK documentation mode uses different input, of course, for different versions. First broken version is 1.24-dev-0.0.

The crash seems to occur at different places somewhat non-deterministically from the Dart code's perspective but has the same backtrace in all instances; most of the time we're somewhere in the middle of documenting DomMatrix class but we never seem to crash in the exact same place. Nothing I'm doing in the branch seems bad or obviously likely to cause a problem, but without the change, the crash vanishes.

[jcollins-g]

I've narrowed it down to one bit that seems to cause the crash. Sadly the crash is not reproducible using the dart debugger or I'd be able to get you more data:

https://github.com/dart-lang/dartdoc/blob/warnings-update/lib/src/model.dart#L223

Here, calling accessor.name will sometimes, indeterminately, cause a crash. If I don't call accessor.name, say if I just return null, or if I call other members of accessor like nameLength or enclosingElement, there doesn't seem to be a problem. The crash is clearly data dependent; something in the dart:html library seems to exercise a path that leads to the crash, but since the dart debugger can't reproduce the problem I'm having difficulty localizing it. This code is not part of the delta in the branch, but we are using it more heavily in the branch due to the new documentationFrom method.

[mraleph]

Thanks for looking into this yourself @jcollins-g! Just to give you a bit of background - based on the stack trace, it's a crash in the optimizing JIT compiler - which runs in the background concurrently with the main execution thread and optimizes hot functions. This probably explains why the crash is non-deterministic - because background compiler is inherently racing with the execution... This also explains why you can't reproduce the bug in the debugger - whenever you use debugger VM usually stops background compiler and prevent more functions from being optimized to give you better debugging experience.

From the stack trace I can also guess that one of the most likely reasons for the crash is that we are trying to emit a jump to a NULL deoptimization label.

Could you post the command line / instructions that reproduce the crash most reliably for you? I am away today, but I will take a close look tomorrow.

[jcollins-g]

Some other things I've tried that all still result in a crash: changing the declaration of accessor to an explicit type (PropertyAccessorElement), not calling replaceFirst on the name but just calling the name in a print statement, running without checked mode.

It is almost certainly a coincidence but it seems strangely linked to #29600. The crash will only occur if the accessor is actually a PropertyAccessorMember rather than a PropertyAccessorElementImpl, and goes away if I repeatedly call baseElement on the member and then call name on the PropertyAccessorElementImpl.

[jcollins-g]

Some basic instructions that should reproduce this quickly:

First, ensure that you have a 1.24+ Linux SDK installed. Then:

git clone git@github.com:dart-lang/dartdoc.git
cd dartdoc
git checkout origin/warnings-update
pub get
dart bin/dartdoc.dart --output /tmp/sdkdocs --sdk-docs --show-progress
[... to crash ...]

[jcollins-g]

@mraleph thanks for looking at this, please let me know if I can be of further help!

[jcollins-g]

I've closed the original PR motivating this but left the branch in place for you to reproduce the problem; dart-lang/dartdoc#1428 has the workaround so I can be unblocked while you investigate.

[mraleph]

@jcollins-g thanks!

I have already figured out what the problem is - my original guess was correct. I just need to think a little bit more about how to fix it best.

[mraleph]

CL with a fix is up for review: https://codereview.chromium.org/2891113002/

[mraleph]

Should be fixed now. Thanks a lot for reporting and providing the reproduction, @jcollins-g!