[英]Why doesn't the JVM crash when entering infinite recursion?
我正在編寫一個要加載到JVM中的共享庫,下面的行為讓我陷入困境。 這是我的Java類:
package com.test;
public class UnixUtil {
static {
System.loadLibrary("myfancylibrary");
}
static native int openReadOnlyFd(String path);
static native int closeFd(int fd);
}
public class Main {
public static void main(String[] args){
int fd = UnixUtil.openReadOnlyFd("/tmp/testc");
UnixUtil.closeFd(fd);
}
}
要加載的庫看起來像:
test_jni.h
/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class com_test_UnixUtil */
#ifndef _Included_com_test_UnixUtil
#define _Included_com_test_UnixUtil
#ifdef __cplusplus
extern "C" {
#endif
/*
* Class: com_test_UnixUtil
* Method: openReadOnlyFd
* Signature: (Ljava/lang/String;)I
*/
JNIEXPORT jint JNICALL Java_com_test_UnixUtil_openReadOnlyFd
(JNIEnv *, jclass, jstring);
/*
* Class: com_test_UnixUtil
* Method: closeFd
* Signature: (I)I
*/
JNIEXPORT jint JNICALL Java_com_test_UnixUtil_closeFd
(JNIEnv *, jclass, jint);
#ifdef __cplusplus
}
#endif
#endif
test_jni.c
#include "test_jni.h"
#include "fs.h"
JNIEXPORT jint JNICALL Java_com_test_UnixUtil_openReadOnlyFd
(JNIEnv *e, jclass jc, jstring path){
const char *const native_path = ((*e) -> GetStringUTFChars)(e, path, NULL);
int fd = read_only_open(native_path);
((*e) -> ReleaseStringUTFChars)(e, path, native_path);
return fd;
}
JNIEXPORT jint JNICALL Java_com_test_UnixUtil_closeFd
(JNIEnv *e, jclass jc, jint fd){
printf("Closing files descriptord %d... \n", fd);
return close(fd);
}
fs.h文件
#ifndef FS_H
#define FS_H
int read_only_open(const char *path);
int close(int fd);
#endif //FS_H
fs.c
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <stdio.h>
#include <sys/fcntl.h>
#include "fs.h"
int read_only_open(const char *path){
printf("Entering %s.%s:%d\n", __FILE__, __func__, __LINE__);
int fd = open(path, O_RDONLY);
return fd;
}
int close(int fd){ //Java_com_test_UnixUtil_closeFd does not invoke this function
printf("Entering %s.%s:%d\n", __FILE__, __func__, __LINE__);
int close_result = close(fd);
return close_result;
}
在編譯和運行此Main
類時,JVM 不會崩潰 。 它根本不輸入函數fs.h::close(int)
。 相反,在GDB中可以看到stdlib
的close
:
Thread 2 "java" hit Breakpoint 1, Java_com_test_UnixUtil_closeFd (e=<optimized out>,
jc=<optimized out>, fd=4) at /home/rjlomov/test_jni/src/main/java/com/test/lib/test_jni.c:17
17 return close(fd);
(gdb) step
18 }
(gdb)
17 return close(fd);
(gdb)
__close (fd=4) at ../sysdeps/unix/sysv/linux/close.c:27
27 ../sysdeps/unix/sysv/linux/close.c: No such file or directory.
(gdb)
26 in ../sysdeps/unix/sysv/linux/close.c
運行objdump -dS libmyfancylibrary.so
顯示了這一點
JNIEXPORT jint JNICALL Java_com_test_UnixUtil_closeFd
(JNIEnv *e, jclass jc, jint fd){
7d0: 53 push %rbx
}
//...
return close(fd);
7e9: e9 62 fe ff ff jmpq 650 <close@plt> // <--- PLT section,
// resolved by linker to stdlib::close?
7ee: 66 90 xchg %ax,%ax
問題:為什么在Java_com_test_UnixUtil_closeFd
而不是fs.c::close(int)
調用stdlib::close
? 我唯一可以想象的是JVM有自己的動態鏈接器來完成工作......
由於您正在編譯共享庫,並且函數close()
不是static
,因此編譯器通過過程鏈接表(PLT)進行間接調用。 拆卸庫時,您可能會看到一條指令
call <close@plt>
當加載myfancylibrary
,該進程已經從libc實現了close
,因此動態liker更新PLT以指向libc的close()
版本。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.