Fix sticky error propagation from thread to isolate

runtime/vm/dart_api_impl.cc

Index: runtime/vm/dart_api_impl.cc
diff --git a/runtime/vm/dart_api_impl.cc b/runtime/vm/dart_api_impl.cc
index 3b944879423ec998be1a7257025eca1fb45ec39a..f3a04a4c0de4e0f660036c0db00eca64428f241e 100644
--- a/runtime/vm/dart_api_impl.cc
+++ b/runtime/vm/dart_api_impl.cc
@@ -1627,9 +1627,10 @@ DART_EXPORT Dart_Handle Dart_RunLoop() {
     }
   }
   ::Dart_EnterIsolate(Api::CastIsolate(I));
-  if (T->sticky_error() != Object::null()) {
-    Dart_Handle error = Api::NewHandle(T, T->sticky_error());
-    T->clear_sticky_error();
+  T = Thread::Current();

[siva, 2016/03/09 07:07:51]

Do we need this here since Api::NewHandle is called in the error path we could
just do:
Dart_Handle error = Api::NewHandle(Thread::Current(), I->o.....);

[Ivan Posva, 2016/03/09 08:27:18]

Why is this even necessary. How can T have changed between the call at the top
of this function and here?

[srdjan, 2016/03/09 19:10:15]

Done.

[srdjan, 2016/03/09 19:10:15]

::Dart_EnterIsolate(...)  sets new Thread::Current(); incidentally it is the
same thread as in T, since we reuse the just released thread (thread =
GetFromFreelistLocked(isolate)). That is how we were accidentally (but
correctly) passing sticky_error, and why clearing sticky_error when unscheduling
broke code. 

+  if (I->object_store()->sticky_error() != Object::null()) {
+    Dart_Handle error = Api::NewHandle(T, I->object_store()->sticky_error());
+    I->object_store()->clear_sticky_error();
     return error;
   }
   if (FLAG_print_class_table) {