JNI Java对象实例化期间的Segfault

时间：2017-10-24 20:31:26

标签： java c++ java-native-interface

（我知道this issue。这是一个单独的问题。）

从C ++ JNI代码实例化Java对象时，我遇到了段错误。

这是段错误：

#  SIGSEGV (0xb) at pc=0x00007f2c7ba13548, pid=2809, tid=139829052933888
#
# JRE version: Java(TM) SE Runtime Environment (8.0_45-b14) (build 1.8.0_45-b14)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.45-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# V  [libjvm.so+0x559548]  Dictionary::add_protection_domain(int, unsigned int, instanceKlassHandle, ClassLoaderData*, Handle, Thread*)+0x128

这是hs_err文件中堆栈的相关部分：

Stack: [0x00007f2c7cf78000,0x00007f2c7d079000],  sp=0x00007f2c7d0760c0,  free space=1016k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x559548]  Dictionary::add_protection_domain(int, unsigned int, instanceKlassHandle, ClassLoaderData*, Handle, Thread*)+0x128
V  [libjvm.so+0xa1f4e2]  SystemDictionary::validate_protection_domain(instanceKlassHandle, Handle, Handle, Thread*)+0x142
V  [libjvm.so+0xa230d4]  SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*)+0x3c4
V  [libjvm.so+0xa24a13]  SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, Thread*)+0x33
V  [libjvm.so+0x4ea4f8]  ConstantPool::klass_at_impl(constantPoolHandle, int, Thread*)+0x158
V  [libjvm.so+0x4efbd0]  ConstantPool::klass_ref_at(int, Thread*)+0xa0
V  [libjvm.so+0x7e0eb1]  LinkResolver::resolve_pool(KlassHandle&, Symbol*&, Symbol*&, KlassHandle&, constantPoolHandle, int, Thread*)+0x71
V  [libjvm.so+0x7e7206]  LinkResolver::resolve_invokeinterface(CallInfo&, Handle, constantPoolHandle, int, Thread*)+0xa6
V  [libjvm.so+0x7e9ad0]  LinkResolver::resolve_invoke(CallInfo&, Handle, constantPoolHandle, int, Bytecodes::Code, Thread*)+0xb0
V  [libjvm.so+0x67a972]  InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code)+0x1b2
j  [my-package].NativeRef$X509_ATTRIBUTE.<init>(J)V+21
v  ~StubRoutines::call_stub
V  [libjvm.so+0x681a26]  JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x1056
V  [libjvm.so+0x6c432b]  jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)+0x41b
V  [libjvm.so+0x6d943b]  jni_NewObjectV+0x2ab
C  [[my-so].so+0x2b855]  JNIEnv_::NewObject(_jclass*, _jmethodID*, ...)+0xb5
C  [[my-so].so+0x7d31e]  _jobject* newNativeRef<UniquePtr<x509_attributes_st, X509_ATTRIBUTE_Delete> >(JNIEnv_*, char const*, UniquePtr<x509_attributes_st, X509_ATTRIBUTE_Delete>*, bool)+0x352

我的库的快速概述：我的代码包含OpenSSL，通过JCA API为Java应用程序提供对OpenSSL的访问。 （注意：并非所有代码都是从头开始编写的。有些代码来自Conscrypt，Android库执行类似的功能。）

我有许多几乎相同的类（本机指针的简单Java包装器，它自动从finalize（）方法中释放本机对象），它们都扩展了一个名为NativeRef的类。 （部分代码如下。）

因此，我创建了一个公共本机函数（newNativeRef（））来获取本机指针并实例化一个Java对象，将本机指针传递给构造函数。该功能已使用超过一年，并经过严格测试。到目前为止我没有遇到任何问题。 （部分代码如下）

但我现在正在编写一个新的JNI函数，它调用newNativeRef（）并给出段错误。

这是我正在编写的新JNI函数中的调用：

ret = newNativeRef<Unique_X509_ATTRIBUTE>(env, CLASS_NR_X509_ATTRIBUTE, &attr, false);

attr是一个简单的智能指针（Unique_X509_ATTRIBUTE），它包含指向OpenSSL X509_ATTRIBUTE对象的基本指针。

CLASS_NR_X509_ATTRIBUTE被定义为“[my-package] / NativeRef $ X509_ATTRIBUTE”

以下是Unique_X509_ATTRIBUTE的定义：

struct X509_ATTRIBUTE_Delete {
    void operator()(X509_ATTRIBUTE* p) const {
        X509_ATTRIBUTE_free(p);
    }
};
typedef UniquePtr<X509_ATTRIBUTE, X509_ATTRIBUTE_Delete> Unique_X509_ATTRIBUTE;

以下是来自UniquePtr

的相关（修剪后的）代码 
template <typename T, typename D = DefaultDelete<T> >
class UniquePtr {
public:
    // Construct a new UniquePtr, taking ownership of the given raw pointer.
    explicit UniquePtr(T* ptr = (T*) NULL) : mPtr(ptr) {
    }

    T* get() const { return mPtr; }

    // Returns the raw pointer and hands over ownership to the caller.
    // The pointer will not be deleted by UniquePtr.
    T* release() CJ_ATTRIBUTE(((warn_unused_result))){
        T* result = mPtr;
        mPtr = NULL;
        return result;
    }

    // Takes ownership of the given raw pointer.
    // If this smart pointer previously owned a different raw pointer, that
    // raw pointer will be freed.
    void reset(T* ptr = (T*) NULL) {
        if (ptr != mPtr) {
            D()(mPtr); // Basically, this calls X509_ATTRIBUTE_free(mPtr)
            mPtr = ptr;
        }
    }

private:
    // The raw pointer.
    T* mPtr;
};

以下是发生段错误的功能：

template<typename T> jobject newNativeRef(JNIEnv* env, const char* className,
        T* addr) {

    jclass clazz;
    jobject object = JNIHandle_NULL;

    try {

        clazz = env->FindClass(className);
        [snip - error-checking]

        jmethodID constructor = env->GetMethodID(clazz, "<init>",
                NATIVE_FUNC_SIG(SIG_VOID, SIG_LONG));

        jlong jaddr = JNIHandle_NULL;

        if (addr != NULL) {
            jaddr =
                    static_cast<jlong>(reinterpret_cast<uintptr_t>((*addr).get()));
        }

        // This line generates the segfault.
        object = env->NewObject(clazz, constructor, jaddr);

        if (addr != NULL) {
            // Ownership of the pointer has been passed to the Java object
            OWNERSHIP_TRANSFERRED((*addr));
        }

    [snip - error handling]

    return object;
}

NATIVE_FUNC_SIG（SIG_VOID，SIG_LONG）评估为“（J）V”

这是用于包装指向X509_ATTRIBUTE对象的Java类（即我们尝试创建实例的类）：

public static class X509_ATTRIBUTE extends NativeRef {
    public X509_ATTRIBUTE(long ctx) {
        super(ctx);
    }

    protected void opensslFree() {
        [Native-function-class].X509_ATTRIBUTE_free(this);
    }
}

还有NativeRef超类（裁剪）：

public abstract class NativeRef {

    transient volatile long context = 0L;

    public NativeRef(long ctx) {
        this.context = ctx;
    }

    @Override
    protected synchronized void finalize() throws Throwable {
        try {
            free();
        } finally {
            super.finalize();
        }
    }

    public synchronized void free() {
        try {
            if (isValid()) {
                opensslFree();
            }
        } finally {
            context = 0L;
        }
    }

    protected abstract void opensslFree();
}

提前致谢！

[编辑]

有趣的是，崩溃似乎并不特定于此newNativeRef（）调用。在注释掉newNativeRef（）调用之后，下次JNI尝试实例化Java对象时会显示相同的段错误（在本例中为Java异常）。

我甚至看到了与不包含任何JNI代码的堆栈跟踪相同的段错误。以下是来自此类崩溃的hs_err堆栈跟踪：

Stack: [0x00007f8535bf7000,0x00007f8535cf8000],  sp=0x00007f8535cf5bf0,  free space=1018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x559548]  Dictionary::add_protection_domain(int, unsigned int, instanceKlassHandle, ClassLoaderData*, Handle, Thread*)+0x128
V  [libjvm.so+0xa1f4e2]  SystemDictionary::validate_protection_domain(instanceKlassHandle, Handle, Handle, Thread*)+0x142
V  [libjvm.so+0xa230d4]  SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*)+0x3c4
V  [libjvm.so+0xa24a13]  SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, Thread*)+0x33
V  [libjvm.so+0x4ea4f8]  ConstantPool::klass_at_impl(constantPoolHandle, int, Thread*)+0x158
V  [libjvm.so+0x89d141]  Method::fast_exception_handler_bci_for(methodHandle, KlassHandle, int, Thread*)+0x141
V  [libjvm.so+0x6774dd]  InterpreterRuntime::exception_handler_for_exception(JavaThread*, oopDesc*)+0x32d
j  CertRequest.setAttribute(Ljava/lang/String;Ljava/lang/String;)V+32
j  MyApp.run()V+176
j  MyApp.main([Ljava/lang/String;)V+7
v  ~StubRoutines::call_stub
V  [libjvm.so+0x681a26]  JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x1056
V  [libjvm.so+0x6c3692]  jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*)+0x362
V  [libjvm.so+0x6e009a]  jni_CallStaticVoidMethod+0x17a
C  [libjli.so+0x7bcc]  JavaMain+0x80c
C  [libpthread.so.0+0x7dc5]  start_thread+0xc5

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  CertRequest.setAttribute(Ljava/lang/String;Ljava/lang/String;)V+32
j  MyApp.run()V+176
j  MyApp.main([Ljava/lang/String;)V+7
v  ~StubRoutines::call_stub

1 个答案:

答案 0 :(得分：0)

原来一个早期的函数破坏了一些内存，这会在JNI的下一次Java调用期间导致半随机错误。

相关问题
最新问题