---
title: 基于Hadoop 3.2.0版本的libhdfs.so，执行Spark查询Parquet数据源偶发core dump问题的解决方法
description: "使用Spark查询Parquet数据源时，若开启OmniOperator并依赖Hadoop 3.2.0版本的libhdfs.so时，会偶发core dump，报错堆栈如下。"
url: https://www.hikunpeng.com/document/detail/zh/kunpengboostkithistory/2530/bds/kunpengbds_omniruntime_20_0234.html
sourcePath: /source/zh/kunpengboostkithistory/2530/bds/kunpengbds_omniruntime_20_0234.html
indexId: 12af392fee7d2c657285a114ba6dd601b23e54ba75874cbe0a890e06852b174878
---
# 基于Hadoop 3.2.0版本的libhdfs.so，执行Spark查询Parquet数据源偶发core dump问题的解决方法

#### 问题现象描述

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

```
Stack: [0x00007fb9e8e5d000,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
[0x00007fbbc0012ab0] AdapterHandlerLibrary_lock - owner thread: 0x00007fba04451800

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


#### 关键过程、根本原因分析

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


#### 结论、解决方案及效果

通过提前判断操作系统中JVM是否存在，并在确认JVM存在的情况下，基于已获取的JNIEnv指针对当前线程执行detach操作，可以有效规避JNIEnv为野指针时引发的core dump异常。使用本版本提供的libhdfs.so可以规避该问题。或者使用社区的Patch重新编译libhdfs.so。可参考GitHub(https://github.com/apache/hadoop/pull/5955)。