基于Hadoop 3.2.0版本的libhdfs.so，执行Spark查询Parquet数据源偶现coredump问题的解决方法

问题现象描述

使用Spark查询Parquet数据源时，若开启OmniOperator并依赖Hadoop 3.2.0版本的libhdfs.so时，会偶现coredump，报错堆栈如下。

      
           Stack: [Ox00007fb9e8e5d000,0x00007fb9e8f5e000], sp=0x00007fb9e8f5cd40, free space=1023k
Native frames: (J=compiled Java code, j=interpreted , Vv=VM code, C=native code)
C [libhdfs.so+0xcd39]  hdfsThreadDestructor+0xb9
------------------  PROCESS  ------------------  
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: ([ mutex/lock event])
[0x00007fbbc00119b0] CodeCache_lock - owner thread: 0x00007fbbc00d9800
[Ox00007fbbc0012ab0] AdapterHandlerLibrary_lock - owner thread: 0x00007fba04451800

heap address: 0x00000000c0000000, size: 1024 MB, Compressed 0ops mode: 32-bit
Narrow klass base: 0x0000000000000000, Narrow klass shift: 3
Compressed class space size: 1073741824 Address: 0x0000000100000000

关键过程、根本原因分析

这是Hadoop 3.2.0的一个BUG，链接如下：https://issues.apache.org/jira/browse/HDFS-15270。如果在JVM退出后再调用JNIEnv获取JVM信息，会造成coredump。但是该BUG的社区修复未完全解决该问题，还是存在偶发性的coredump，原因在于未考虑JNIEnv是野指针的情况。

结论、解决方案及效果

通过提前判断操作系统中JVM是否存在，若存在则基于获取的JVM指针对当前线程进行detach，来避免JNIEnv为野指针时产生的coredump异常。使用本版本提供的libhdfs.so可以规避该问题。或者使用社区的Patch重新编译libhdfs.so。链接如下：https://github.com/apache/hadoop/pull/5955

父主题： OmniOperator算子加速