Сбой агента JVMTI

Я работаю над реализацией алгоритма обнаружения гонки данных стирателя в качестве агента JVMTI. Когда я пытаюсь запустить некоторые примеры входных данных для проверки своего кода, JVM падает с дампами, подобными следующему (могут также отображаться другие трассировки стека для той же ошибки):

FATAL ERROR in native method: Using JNIEnv in the wrong thread at Proxy.monitor_enter_(Native Method) at Proxy.monitor_enter(Proxy.java:30) at ex1.LifeThreads.setNeighborThreadChange(LifeThreads.java:36) at ex1.LifeThreads.neighbor(LifeThreads.java:425) at ex1.LifeThreads.standardItr(LifeThreads.java:321) at ex1.LifeThreads.run(LifeThreads.java:462)

(Такую трассировку можно получить с помощью параметра -Xcheck:jni для Sun JVM)

В коде я использую тот же инструментарий, что и в различных примерах JDK (heapViewer, heapTracker и т. д., через некоторый прокси-класс java с собственными методами). Proxy.monitor_enter_ собственный метод вызывается после каждой monitorenter инструкции.

Это код для monitor_enter_:

void native_monitor_exit(JNIEnv *jni, jclass klass, jthread thread_id, jobject obj)
{
    scoped_lock( agent::instance()->jvmti(), agent::instance()->monitor_ );
        if( agent::instance()->death_active_)
                return;

    std::string name = agent::instance()->thread_name( thread_id );
        thread_t* thread = get_thread( thread_id );
        if( thread == 0 )
            return;
        jobject global_ref = agent::instance()->jni()->NewGlobalRef( obj );
        if( global_ref == 0 )
                fatal_error("Out of memory while trying to create new global ref.");

    logger::instance()->level(1) << "MONITOR ENTER"
                << "\n\t" << "jthread name= " << name
                << "\n\t" << "thread_t= " << thread << " " << *thread
                << "\n\t" << "monitor gl= " << global_ref
                << std::endl;

        thread->lock( lock(global_ref) );
}

, где scoped_lock в основном представляет собой блокировку области действия для входа/выхода JVMTI Raw Monitor, thread_t - это просто структура, обертывающая некоторые std::vector, где хранится экземпляр класса lock (который сам просто обертывает jobject глобальную ссылку global_ref), когда thread->lock( lock(global_ref)) вызывается.

Оболочка JVMTI. кэшируется глобально в агенте singleton, тогда как JNI env, который является локальным для потока, перезагружается каждый раз перед его использованием (что не так эффективно, но пока мне все равно), как показано ниже:

    JNIEnv* jni()
{
    jint res;
    JNIEnv* env = 0;
    res = jvm()->GetEnv( (void**)&env, JNI_VERSION_1_2 );
    if( res == JNI_EDETACHED )
    {
        res = jvm()->AttachCurrentThread( (void **)&env, 0 );
        if( res != JNI_OK || env == 0 )
            fatal_error( "ERROR: Unable to create JNIEnv by attach, error=%d\n", res );
    }
        else if( res != JNI_OK || env == 0 )
        fatal_error( "ERROR: Unable to create JNIEnv, error=%d\n", res );
    }
    return env;
}