Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Fix potential deadlock because unlocking might GC

We might have to wait for a GC when unlocking the locked objects. This
also means we have to clear the call frame before that because it's not
valid anymore.
  • Loading branch information...
commit ef023b2af56cc79c5bba7797f0efbdb356e2a1e2 1 parent 2c2c6b1
@dbussink dbussink authored
Showing with 2 additions and 3 deletions.
  1. +2 −3 vm/builtin/thread.cpp
View
5 vm/builtin/thread.cpp
@@ -258,8 +258,7 @@ namespace rubinius {
}
}
- vm->thread->init_lock_.lock();
-
+ vm->set_call_frame(0);
std::list<ObjectHeader*>& los = vm->locked_objects();
for(std::list<ObjectHeader*>::iterator i = los.begin();
@@ -268,6 +267,7 @@ namespace rubinius {
(*i)->unlock_for_terminate(state, gct);
}
+ vm->thread->init_lock_.lock();
NativeMethod::cleanup_thread(state);
vm->thread->alive(state, cFalse);
@@ -276,7 +276,6 @@ namespace rubinius {
// Clear the call_frame, so that if we wait for GC going independent,
// the GC doesn't see pointers into now-unallocated CallFrames
- vm->set_call_frame(0);
vm->shared.gc_independent(state);
vm->shared.clear_critical(state);
Please sign in to comment.
Something went wrong with that request. Please try again.