Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flaky segmentation faults in benchmark-linux-try builder #33999

Closed
athomas opened this issue Jul 27, 2018 · 4 comments
Closed

Flaky segmentation faults in benchmark-linux-try builder #33999

athomas opened this issue Jul 27, 2018 · 4 comments
Assignees
Labels
area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends. P1 A high priority bug; for example, a single project is unusable or has many test failures

Comments

@athomas
Copy link
Member

athomas commented Jul 27, 2018

The benchmark-linux-try builder has been failing flakily with segmentation faults recently:
https://ci.chromium.org/p/dart/builders/luci.dart.try/benchmark-linux-try
https://logs.chromium.org/logs/dart/buildbucket/cr-buildbucket.appspot.com/8939865024071580336/+/steps/try_linux-x64_benchmarking/0/stdout

@a-siva @mkustermann I'm marking this as P1 because it happens frequently and might indicate a general instability in Dart. Feel free to change the priority.

@athomas athomas added P1 A high priority bug; for example, a single project is unusable or has many test failures area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends. labels Jul 27, 2018
@mkustermann mkustermann self-assigned this Jul 27, 2018
@mkustermann
Copy link
Member

I've got this issue reproduced in gdb and here's some information:

The AssertAssignableInstr::Canonicalize finds that function type args and instantiator type args are constant and tries to instantiate the destination type T. The type parameter T has index 2 but the length of instantiator type args is only 1.

In my reproduction this happens during optimization of the KernelTarget.finishConstructors method.

The corresponding block looks like this:

$100 = (dart::TargetEntryInstr *) 0x55bbec338e58
$101 = (dart::BranchInstr *) 0x55bbec339518

$93 = (dart::TargetEntryInstr *) 0x55bbec3399c8
$92 = (dart::RedefinitionInstr *) 0x55bbec339ef8
$91 = (dart::CheckClassIdInstr *) 0x55bbec339fb0
$90 = (dart::RedefinitionInstr *) 0x55bbec337208
$89 = (dart::LoadFieldInstr *) 0x55bbe8b9c508  _source@9040228
$88 = (dart::LoadFieldInstr *) 0x55bbe8b9c850   dart::NativeFieldDesc::kGrowableObjectArray_length
$87 = (dart::CheckArrayBoundInstr *) 0x55bbe8b9c938
$86 = (dart::LoadFieldInstr *) 0x55bbe8b9cb68
$94 = (dart::LoadIndexedInstr *) 0x55bbe8b9cc50
$140 = (dart::AssertAssignableInstr *) 0x55bbe8b9cdb0  // XXXXX _CastListBase.T = 
$96 = (dart::GotoInstr *) 0x55bbec33b700

$104 = (dart::JoinEntryInstr *) 0x55bbec33a488
$105 = (dart::RedefinitionInstr *) 0x55bbec2872e8
$106 = (dart::StoreInstanceFieldInstr *) 0x55bbec288900  _current =
$107 = (dart::BinarySmiOpInstr *) 0x55bbec288b48
$108 = (dart::StoreInstanceFieldInstr *) 0x55bbec288e68  _index =
$109 = (dart::LoadFieldInstr *) 0x55bbec252650 
$110 = (dart::BranchInstr *) 0x55bbec252bf0

The value of the instantiator type args is [Field] whereas T seems to be _CastListBase.T.

@mkustermann
Copy link
Member

@mraleph

@mraleph
Copy link
Member

mraleph commented Jul 27, 2018

Based on the info that @mkustermann provided I think this is probably caused by unreachable code that was not removed. Reduction:

class M<U, T> {
   T field;
 }

 class C<T> {
   T field;
 }

 var TRUE = true;

 void foo(bool f) {
   dynamic x = f ? C<int>() : M<String, int>();
   if (f == TRUE) {
     x.field = 10;
   } else {
     x.field = 10;
   }
 }

 void bar() {
   foo(true);
 }


 void main() {
   foo(true);
   foo(false);
   for (var i = 0; i < 100000; i++) bar();
 }

this causes this

../../runtime/vm/object.cc: 16731: error: unreachable code
Dumping native stack trace for thread 21adf
  [0x000056317a9fc7ff] dart::Profiler::DumpStackTrace(void*)
  [0x000056317a9fc7ff] dart::Profiler::DumpStackTrace(void*)
  [0x000056317ac38722] dart::Assert::Fail(char const*, ...)
  [0x000056317a9760b3] Unknown symbol
  [0x000056317aaebfe0] dart::AssertAssignableInstr::Canonicalize(dart::FlowGraph*)
  [0x000056317aad47db] dart::FlowGraph::Canonicalize()
  [0x000056317ab51b22] Unknown symbol
  [0x000056317ab51425] dart::CompilerPass::Run(dart::CompilerPassState*) const
  [0x000056317ab51379] dart::CompilerPass::Run(dart::CompilerPassState*) const
  [0x000056317ab516b2] dart::CompilerPass::RunPipeline(dart::CompilerPass::PipelineMode, dart::CompilerPassState*)
  [0x000056317abd4d1a] dart::CompileParsedFunctionHelper::Compile(dart::CompilationPipeline*)
  [0x000056317abd5b9a] Unknown symbol
  [0x000056317abd6b77] dart::Compiler::CompileOptimizedFunction(dart::Thread*, dart::Function const&, long)
  [0x000056317aa58ea2] dart::DRT_OptimizeInvokedFunction(dart::NativeArguments)
  [0x00007fa32d74091b] [Stub] CallToRuntime
  [0x00007fa32d740cd0] [Stub] OptimizeFunction
  [0x00007fa3281ea66c] main
  [0x00007fa3281ea473] main
  [0x00007fa3281ea332] _Closure.call
  [0x00007fa3281e9658] _startIsolate.<anonymous closure>
  [0x00007fa3281ca3d5] _Closure.call
  [0x00007fa3281e92dc] _RawReceivePortImpl._handleMessage
  [0x00007fa32d740da3] [Stub] InvokeDartCode
  [0x000056317a8ab4a9] dart::DartEntry::InvokeFunction(dart::Function const&, dart::Array const&, dart::Array const&, unsigned long)
  [0x000056317a8aec63] dart::DartLibraryCalls::HandleMessage(dart::Object const&, dart::Instance const&)
  [0x000056317a8d8c3b] dart::IsolateMessageHandler::HandleMessage(dart::Message*)
  [0x000056317a9081ea] dart::MessageHandler::HandleMessages(dart::MonitorLocker*, bool, bool)
  [0x000056317a90895c] dart::MessageHandler::TaskCallback()
  [0x000056317aa9a0ed] dart::ThreadPool::Worker::Loop()
  [0x000056317aa99f84] dart::ThreadPool::Worker::Main(unsigned long)
  [0x000056317a9ab419] Unknown symbol
-- End of DumpStackTrace

@mkustermann
Copy link
Member

Slava's change should've fixed this issue.

dart-bot pushed a commit that referenced this issue Jul 30, 2018
…ignable.

Our IL graphs can contain portions that can not be reached due to execution
and all optimizations need to take that into account.

In this particular case AssertAssignable::Canonicalize should have taken
into account that constant instantiator type arguments might not necessarily
correspond to the correct class - because AssertAssignable is on the
path that will never be reached during execution.

Fixes #33999

Bug: http://dartbug.com/33999
Change-Id: Ia151a3902b2bc7f0f8d4aa6dcdb302fe6b1d626d
Reviewed-on: https://dart-review.googlesource.com/67321
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends. P1 A high priority bug; for example, a single project is unusable or has many test failures
Projects
None yet
Development

No branches or pull requests

3 participants