JNIJava对象实例化过程中的分段故障

Question

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

我从C JNI代码实例化Java对象时得到了一个segfault。

这是分段故障：

#  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，通过JCAAPI为Java应用程序提供对OpenSSL的访问。（注意：并非所有代码都是从零开始编写的。一些代码源于执行类似功能的Android库Conscrypt。）

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

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

但是我现在正在编写一个新的JNI函数，它调用newNativeRef()并给出segfault。

下面是我正在编写的新JNI函数中的调用:

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

attr是一个简单的智能指针（Unique_X509_ATTRIBUTE），它环绕着指向OpenSSLX509_ATTRIBUTE对象的基本指针。

CLASS_NR_X509_ATTRIBUTE被定义为“[my-package]/native ref＄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;
};

下面是发生segfault的函数:

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”

下面是一个Java类，用于包装指向X509_

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异常）时，会显示相同的segfault。

我甚至在不包含我的任何JNI代码的stacktraces中看到过相同的segfault。下面是这样一个崩溃的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

Answer 1

事实证明，早期的函数正在损坏一些内存，这将在JNI的下一次Java调用期间导致半随机错误。