Java運行時環境檢測到致命錯誤

Question

我正在嘗試使用C ++運行一個簡單的Java程序並編寫以下代碼 -

1 #include <jni.h>
2 #include <stdio.h>
3
4 JNIEnv * create_vm() {
5     JavaVM *jvm;
6     JNIEnv *env;
7     JavaVMInitArgs vm_args;
8
9     JavaVMOption options[1];
10
11     options[0].optionString = "-Djava.class.path=~/openbr/java/JavainC";
12     vm_args.version = JNI_VERSION_1_6;
13     vm_args.nOptions = 1;
14     vm_args.options = options;
15     vm_args.ignoreUnrecognized = JNI_FALSE;
16
17     int res = JNI_CreateJavaVM(&jvm, (void**)&env, &vm_args);
18     return env;
19 }
20
21 void run_java(JNIEnv* env) {
22     jclass cls;
23     jmethodID mid;
24     jint square;
25
26     cls = env->FindClass("javaTest");
27     mid = env->GetStaticMethodID(cls, "square", "(I)I");
28     square = env->CallStaticIntMethod(cls, mid, 5);
29     printf("Result of square: %d\n", square);
30 }
31
32 int main() {
33     JNIEnv* env = create_vm();
34     run_java(env);
35     printf("running some code");
36     //jvm->DestroyJavaVM();
37     return 0;
38 }

我的Java代碼看起來像 -

1 public class javaTest {
2     public static int square(int n) {
3         return n*n;
4     }
5 }
6

我的代碼編譯得很好但是當我試圖運行它時，我得到了這個錯誤信息 -

# A fatal error has been detected by the Java Runtime Environment: 
#
#  SIGSEGV (0xb) at pc=0x00007fc3038f984f, pid=12689, tid=140475565049664
#
# JRE version: 7.0_21-b02
# Java VM: OpenJDK 64-Bit Server VM (23.7-b01 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# V  [libjvm.so+0x53284f]  jni_CallStaticIntMethodV+0x4f
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -    c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/jcheney/openbr/java/JavainC/hs_err_pid12689.log
#
# If you would like to submit a bug report, please include
# instructions on how to reproduce the bug and visit:
#   https://bugs.launchpad.net/ubuntu/+source/openjdk-7/
#
Aborted

它給我的錯誤打印輸出說 -

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

Current thread (0x00000000011be800):  JavaThread "main" [_thread_in_vm, id=12689, stack
(0x00007fff54814000,0x00007fff54914000)]

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000000

Registers:
RAX=0x00007fc303c4a138, RBX=0x00000000011be800, RCX=0x00007fff549127c0, RDX=0x00000000011bf318
RSP=0x00007fff549126e0, RBP=0x00007fff54912790, RSI=0x00000000011be800, RDI=0x00000000011be800
R8 =0x00007fc3038f9800, R9 =0x746f7073746f682f, R10=0x6168732f6372732f, R11=0x0000000000000246
R12=0x00000000011be9d8, R13=0x0000000000000000, R14=0x00007fff549127c0, R15=0x0000000000000000
RIP=0x00007fc3038f984f, EFLAGS=0x0000000000010287, CSGSFS=0x0000000000000033,    
ERR=0x0000000000000004
TRAPNO=0x000000000000000e

Top of Stack: (sp=0x00007fff549126e0)
0x00007fff549126e0:   00007fff549126c8 0000000800000002
0x00007fff549126f0:   00007fff54912701 0000000000000000
0x00007fff54912700:   00007fff54912730 00007fc3038125ac
0x00007fff54912710:   00000000011be800 00000000011be800
0x00007fff54912720:   00000000011be800 00000000011bf310
0x00007fff54912730:   00007fff0000063d 00007fc303c4a138
0x00007fff54912740:   0000000000000000 0000000000400901
0x00007fff54912750:   00000000011be800 0000000000000000
0x00007fff54912760:   00000000011be800 0000000000400906
0x00007fff54912770:   0000000000000000 00000000004004d0
0x00007fff54912780:   00007fff549129d0 0000000000000000
0x00007fff54912790:   00007fff54912890 00000000004007cd
0x00007fff549127a0:   0000000000000000 0000000000000000
0x00007fff549127b0:   0000000000000000 00000000011be9d8
0x00007fff549127c0:   0000003000000018 00007fff549128a0
0x00007fff549127d0:   00007fff549127e0 0000000000400901
0x00007fff549127e0:   0000000000000000 0000000000000000
0x00007fff549127f0:   00007fff54912860 0000000000000005
0x00007fff54912800:   00007fc303c3ae8f 746f7073746f682f
0x00007fff54912810:   00007fff000000a8 00007fc303c68e68
0x00007fff54912820:   00000000011be800 00007fff549128c0
0x00007fff54912830:   00000000011be800 00007fc303903233
0x00007fff54912840:   0000000000000000 00000000004004d0
0x00007fff54912850:   00007fff549129d0 0000000000000000
0x00007fff54912860:   00007fff54912890 0000000000400712
0x00007fff54912870:   0000000000400901 0000000000400906
0x00007fff54912880:   0000000000000000 00000000011be9d8
0x00007fff54912890:   00007fff549128d0 000000000040065b
0x00007fff549128a0:   00000000004008d0 00000000011be9d8
0x00007fff549128b0:   00007fff54912930 0000000000000000
0x00007fff549128c0:   0000000000000000 00000000004007e0
0x00007fff549128d0:   00007fff549128f0 0000000000400691

關於發生了什么的任何想法？

謝謝

Answer 1

我的猜測 - 這只是猜測 - 是FindClass或GetStaticMethodId方法FindClass由於某種原因沒有成功，並且由於你沒有檢查錯誤，你的程序最終崩潰試圖通過調用方法一個糟糕的方法指針。 最小化，檢查這兩個方法的返回值是否為NULL ，如果返回它們則失敗。

在@TimBender的催促下，我再次看了你的代碼，我同意 - 它可能是FindClass 。 你絕對不能在你的classpath包含一個~只有shell知道如何解釋它，並且該參數在JVM看到它之前不會通過shell。 實際上，使用類的位置的完整絕對路徑 - 包層次結構的根。

Answer 2

基於有限的研究，我99％確定問題在於FindClass聲明。 FindClass接受第二個參數作為完全限定的類名。 完全限定意味着包名必須包含在類名之前。 我假設javaTest不在默認包中，或者如果它仍然存在一些引用它的約定。