Создание JVM в цикле метода класса C ++ — API вызова

Я обернул библиотеку Java в библиотеку классов C ++ и хочу использовать эту библиотеку в другом проекте C ++.

В частности, я хотел бы использовать библиотеку в методе класса, который читает входной файл, перебирает все элементы в файле, а затем использует библиотеку для выполнения какой-либо операции.

Тем не менее, я пытаюсь выяснить, как именно вызвать JVM правильно. В тот момент мой код выглядит примерно так:

void myclass::method()
{
for (int OBJECT=1; OBJECT < OBJECT_DATA_SIZE; OBJECT++)
{

// CONFIGURE JVM

JavaVMOption jvmopt[1];
jvmopt[0].optionString = "-Djava.class.path=""/PATH/TO/LIB/ONE.jar:""/PATH/TO/LIB/TWO.jar:""/PATH/TO/LIB/THREE.jar";

JavaVMInitArgs vmArgs;
vmArgs.version = JNI_VERSION_10;
vmArgs.nOptions = 1;
vmArgs.options = jvmopt;
vmArgs.ignoreUnrecognized = JNI_FALSE;// CREATE THE JVM

JavaVM *javaVM;
JNIEnv *env;
long flag = JNI_CreateJavaVM(&javaVM, (void**)&env, &vmArgs);

if (flag == JNI_ERR)
{                                                       // Check for errors and if errors exist
std::cout << "\nError creating VM. Exiting...\n" << std::endl;           // Output message to console and exit
env->ExceptionCheck();
env->ExceptionDescribe();
std::abort();
}

javaVM->DestroyJavaVM();     // If not found, destroy VM
}
}

Каждый цикл разрушает и воссоздает JVM. Первая итерация работает нормально, но второй цикл дает сбой и вылетает. Я предполагаю, что это как-то связано с тем, что JVM неправильно закрывается. Содержание журнала:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fa7a7d970c3, pid=32015, tid=32015
#
# JRE version: Java(TM) SE Runtime Environment (10.0.2+13) (build 10.0.2+13)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0.2+13, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x9180c3]  ThreadStateTransition::transition_from_native(JavaThread*, JavaThreadState) [clone .constprop.232]+0x13
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P" (or dumping to /home/code/myProg/core.32015)
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

---------------  S U M M A R Y ------------

Command Line:

Host: Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz, 32 cores, 62G, Ubuntu 18.04.1 LTS
Time: Tue Nov 13 14:44:44 2018 GMT elapsed time: 0 seconds (0d 0h 0m 0s)

---------------  T H R E A D  ---------------

Current thread is native thread

Stack: [0x00007ffcb58f3000,0x00007ffcb59f3000],  sp=0x00007ffcb59f0490,  free space=1013k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x9180c3]  ThreadStateTransition::transition_from_native(JavaThread*, JavaThreadState) [clone .constprop.232]+0x13
V  [libjvm.so+0x91b0a4]  jni_ExceptionCheck+0x34siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x00000000000002e8

Register to memory mapping:

RAX=
[error occurred during error reporting (printing register info), id 0xb]

Registers:
RAX=0x00007fa7a884facb, RBX=0x0000000000000000, RCX=0x0000000000000b40, RDX=0x0000000000000000
RSP=0x00007ffcb59f0490, RBP=0x00007ffcb59f04a0, RSI=0x00007fa7a610b8c0, RDI=0x0000000000000000
R8 =0x00007fa7a610b8c0, R9 =0x00007fa7a8aed7c0, R10=0x000000000000000a, R11=0x0000000000000000
R12=0x0000556a366a6a70, R13=0x0000000000000001, R14=0x00007ffcb59f09a0, R15=0x0000000000000001
RIP=0x00007fa7a7d970c3, EFLAGS=0x0000000000010206, CSGSFS=0x002b000000000033, ERR=0x0000000000000006
TRAPNO=0x000000000000000e

Top of Stack: (sp=0x00007ffcb59f0490)
0x00007ffcb59f0490:   0000556a35a370a0 0000556a366a6800
0x00007ffcb59f04a0:   00007ffcb59f04d0 00007fa7a7d9a0a4
0x00007ffcb59f04b0:   0000000000000001 0000556a35a370a0
0x00007ffcb59f04c0:   00007fa7a6e9a0a0 00007fa7a6e9a0a0

Instructions: (pc=0x00007fa7a7d970c3)
0x00007fa7a7d970a3:   c6 83 29 04 00 00 00 eb 9f 0f 1f 40 00 55 48 89
0x00007fa7a7d970b3:   e5 53 48 89 fb 48 83 ec 08 48 8d 05 08 8a ab 00
0x00007fa7a7d970c3:   c7 87 e8 02 00 00 05 00 00 00 80 38 00 75 0c 48
0x00007fa7a7d970d3:   8d 05 73 a8 b1 00 83 38 01 74 30 48 8d 05 e5 89---------------  P R O C E S S  ---------------

VM state:at safepoint (shutting down)

VM Mutex/Monitor currently owned by a thread:  ([mutex/lock_event])
[0x0000556a366a30d0] Threads_lock - owner thread: 0x0000556a36917800

Heap address: 0x00000003d6c00000, size: 16020 MB, Compressed Oops mode: Zero based, Oop shift amount: 3
Narrow klass base: 0x0000000000000000, Narrow klass shift: 3
Compressed class space size: 1073741824 Address: 0x00000007c0000000

Heap:
garbage-first heap   total 1028096K, used 0K [0x00000003d6c00000, 0x00000007c0000000)
region size 4096K, 1 young (4096K), 0 survivors (0K)
Metaspace       used 3331K, capacity 4480K, committed 4480K, reserved 1056768K
class space    used 280K, capacity 384K, committed 384K, reserved 1048576K
Heap Regions: E=young(eden), S=young(survivor), O=old, HS=humongous(starts), HC=humongous(continues), CS=collection set, F=free, A=archive, TS=gc time stamp, AC=allocation context, TAMS=top-at-mark-start (previous, next)

Что я должен делать по-другому?