Fix sticky error propagation from thread to isolate

runtime/vm/isolate.cc

Index: runtime/vm/isolate.cc
diff --git a/runtime/vm/isolate.cc b/runtime/vm/isolate.cc
index 4b1124785de7ad9019f6e452420de901fca1c876..9d54749cc6bb88aebc774dac1f9229feb0312280 100644
--- a/runtime/vm/isolate.cc
+++ b/runtime/vm/isolate.cc
@@ -2592,6 +2592,7 @@ void Isolate::UnscheduleThread(Thread* thread,
   // so we create a MonitorLocker object which does not do any
   // no_safepoint_scope_depth increments/decrements.
   MonitorLocker ml(threads_lock(), false);
+  thread->isolate()->object_store()->SetStickyErrorFromThread(thread);

[siva, 2016/03/08 08:54:59]

If multiple threads exit at the same time won't this  result in the sticky error
being overwritten to the one exiting last.

[srdjan, 2016/03/08 20:21:09]

Modified code to allow only mutator thread to propagate sticky error to isolate.
'SetStickyError' checks that a sticky error is not overwritten.

   if (!bypass_safepoint) {
     // Ensure that the thread reports itself as being at a safepoint.
     thread->EnterSafepoint();
@@ -2610,6 +2611,7 @@ void Isolate::UnscheduleThread(Thread* thread,
   thread->set_execution_state(Thread::kThreadInVM);
   thread->set_safepoint_state(0);
   thread->clear_pending_functions();
+  thread->clear_sticky_error();
   ASSERT(thread->no_safepoint_scope_depth() == 0);
   // Return thread structure.
   thread_registry()->ReturnThreadLocked(is_mutator, thread);