Thanks Ed for your feedback. I think it is better to comment on JIRA HDFS-13585 directly. And feel free to submit PR there if interested and there will be some reviewers coming soon. Please let me know if you will have any questions. Thanks again.
Best Regards, - He Xiaoqiao On Sun, Jul 2, 2023 at 2:07 PM Ed Mancebo <edmanc...@gmail.com> wrote: > Hi, > > I'm new here. I'm wondering if folks will accept a contribution to fix > https://issues.apache.org/jira/browse/HDFS-13585 ? > > I can repro the issue by creating a Java application that calls > hdfsConnectNewInstance: > https://gist.github.com/emancebo/e413b0f53e4005c80cbf410fdb4c9cb9 > > The crash occurs in hdfsThreadDestructor. It seems that any of the calls > on the JNIEnv can cause a crash. I think in this scenario, the JVM (there > is only one - the one created for the Java program) is getting cleaned up > as the application is exiting, hence it is unsafe to call any of the > methods on JNIEnv in the destructor function. > > My idea is to add a check in getGlobalJNIEnv to see if we are already > attached to a JVM (by calling GetEnv). If we're already attached, we don't > need to call AttachCurrentThread, and we can also skip the block of code in > hdfsThreadDestructor that calls DetachCurrentThread. We could add a flag > in ThreadLocalState to indicate whether we need to perform the detach. > > Definitely open to other approaches though. Thanks in advance - > > Ed >
