Flaky crash on iso-stress-linux bot #46823
Comments
alexmarkov
added
area-vm
|
Still crashes: |
|
It seems multiple such crashes happened at precisely Looking at the disassembly of this C++ function, it appears to be crashing when trying to load the void StackTraceUtils::UnwindAwaiterChain(
Zone* zone,
const GrowableObjectArray& code_array,
GrowableArray<uword>* pc_offset_array,
CallerClosureFinder* caller_closure_finder,
const Closure& leaf_closure) {
...
for (; !closure.IsNull(); closure = caller_closure_finder->FindCaller(closure)) {
function = closure.function(); // <-- Crashes here.
if (function.IsNull()) continue;
...
}
}Seems like the By reading through the code I haven't been able to identify how it can happen. Have also had no luck reproducing this so far. |
|
One interesting piece of code is: DartFrameIterator future_frames(frames);
if (function.recognized_kind() == MethodRecognizer::kRootZoneRunUnary) {
frame = future_frames.NextFrame();
...
}The StackFrameIterator::StackFrameIterator(const StackFrameIterator& orig)
: ...
current_frame_(nullptr), // <---
... { ... }So it may not do what is intended there. |
This is an attempt to enable archiving of coredumps on the "iso-stress" builder, since we're often unable to reproduce crashes from that builder. Issue #46823 TEST=Adds test infra. Change-Id: I9b7276198db9a6c98a74f55d466bf832b03e24f8 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214407 Reviewed-by: Alexander Thomas <athom@google.com> Reviewed-by: Slava Egorov <vegorov@google.com> Commit-Queue: Martin Kustermann <kustermann@google.com>
|
Landed 7abf6bf which will hopefully make the builder archive coredumps, then we can analyze the archived dumps. |
|
Have been looking at this issue today. It seems what is happening is that in this code: ClosurePtr StackTraceUtils::ClosureFromFrameFunction(...) {
...
if (function.recognized_kind() == MethodRecognizer::kFutureListenerHandleValue) {
...
// The _FutureListener receiver is at the top of the previous frame, right
// before the arguments to the call.
Object& receiver =
Object::Handle(*(reinterpret_cast<ObjectPtr*>(frame->GetCallerSp()) +
kNumArgsFutureListenerHandleValue));
...
}
...
}the Even though the Looking at the Dart code that seems to make sense: @pragma("vm:recognized", "other")
@pragma("vm:never-inline")
FutureOr<T> handleValue(S sourceResult) {
return _zone.runUnary<FutureOr<T>, S>(_onValue, sourceResult);
}After evaluating Supposedly this is because we don't introduce new We could either make the stack trace collection code more robust or change compiler to avoid modifying the slots in the caller frame. @alexmarkov @mraleph wdyt? |
|
I think we should make stack trace collection more robust. Any variable may become unused after optimizations, so code trying to find variables in the stack frames should be prepared to the absence of the variable or Although parameters are pushed by caller, they are "owned" by the callee and callee can freely modify their values. Making an artificial copy of parameters in the callee seems to be a waste, as caller never looks at the passed parameters. |
|
/cc @cskau-g |
Full log:
https://logs.chromium.org/logs/dart/buildbucket/cr-buildbucket.appspot.com/8839717685687839392/+/u/Run_Isolate_Stress_Tests_shard_2/task_stdout_stderr:_Run_Isolate_Stress_Tests_shard_2
/cc @aam @mkustermann
The text was updated successfully, but these errors were encountered: