Flink Standalone集群TaskManager出现SIGSEGV崩溃问题求助

• 启用核心转储复现场景：重启集群前先执行ulimit -c unlimited开启核心转储权限，下次崩溃后生成的core dump文件可配合gdb工具定位具体原生调用栈，执行gdb $JAVA_HOME/bin/java <core文件路径>即可查看完整的崩溃调用链，确认是否关联RocksDB JNI调用。
• 分析hs_err_pid日志关键字段：查看日志中Current thread部分确认崩溃线程是否为RocksDB读写/ compaction线程，再检查Native frames段落的调用序列，如果出现librocksdbjni相关的栈帧即可确认根因出自RocksDB原生代码。
• 校验RocksDB自定义配置：排查是否开启了非默认配置项，包括自定义压缩算法、状态TTL异步清理、托管内存阈值设置过小等场景，这些配置更易触发RocksDB的原生内存越界问题。

• 升级Flink小版本：Flink 1.10.0版本存在多个已知的RocksDB原生崩溃bug，包括FLINK-16839、FLINK-17296等均是针对SIGSEGV问题的修复，建议直接升级到1.10分支的最终稳定版1.10.3，无需调整业务代码即可修复大部分已知原生崩溃问题。
• 替换RocksDB JNI依赖：若暂时无法升级Flink版本，可手动将集群中flink-statebackend-rocksdb模块依赖的RocksDB JNI版本升级到6.20.3及以上，该版本修复了多个偶发内存访问错误的问题，替换后需做好状态兼容性测试。
• 临时规避方案：可先将出现问题的作业切换为Heap状态后端运行，若切换后崩溃问题消失即可100%确认根因在RocksDB层；也可临时关闭RocksDB托管内存配置state.backend.rocksdb.memory.managed: false，减少JNI层面的内存交互风险。
• 排查JDK版本问题：当前使用的OpenJDK 8u272存在少量JNI调用相关的已知bug，可尝试升级到OpenJDK 8u342以上的稳定版本，排除JDK自身导致的崩溃问题。

内容的提问来源于stack exchange，提问作者Valentina Predtechenskaya