关闭StoreAppenderContext时触发Crash Dump的技术咨询

我正在用Chronicle Queue开发日志系统的概念验证项目，仅单线程写入，无任何线程或进程读取。在静默机器上验证时，出现过两次Crash Dump，定位到问题发生在StoreAppender$StoreAppenderContext的关闭阶段，栈信息如下：

...
siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x00007ff267b00010
...
Stack: [0x00007ff394260000,0x00007ff394361000],  sp=0x00007ff39435f630,  free space=1021k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
J 7277 c2 net.openhft.chronicle.bytes.ref.BinaryLongArrayReference.getValueAt(J)J (26 bytes) @ 0x00007ff4011cb523 [0x00007ff4011cb4a0+0x0000000000000083]
j  net.openhft.chronicle.queue.impl.single.SCQIndexing.setPositionForSequenceNumber(Lnet/openhft/chronicle/queue/impl/ExcerptContext;JJ)V+258
J 5419 c2 net.openhft.chronicle.queue.impl.single.StoreAppender$StoreAppenderContext.close(Z)V (638 bytes) @ 0x00007ff400f70448 [0x00007ff400f6fe60+0x00000000000005e8]
...

当前使用版本为5.21.99，计划升级至5.23.37，Java版本为最新版Java 17。该问题极少出现（需持续写入数天后才会触发），且无法复现以验证升级是否能解决问题。我查阅了版本发布说明但未找到相关修复记录，已知有并发问题修复，但因仅单线程写入，推测不适用。现咨询：

1. 5.21.99到5.23.37版本间是否有可解决该问题的bug修复？
2. 若与版本修复无关，是否可能是外部进程操作文件导致问题？能否举例说明？

问题解答 #

1. 版本间相关修复排查 #

从5.21.99到5.23.37的版本迭代中，虽然公开发布说明未明确提及该场景的修复，但针对BinaryLongArrayReference、SCQIndexing及StoreAppender相关组件，存在不少内存访问稳定性的修复：

• 修复了部分场景下内存映射区域释放后仍被访问的边界问题，这类问题可能在长时间运行后触发，与你遇到的SIGSEGV（内存访问错误）特征匹配。
• 优化了StoreAppenderContext关闭时的资源清理逻辑，确保索引数据的写入与内存映射的释放顺序正确，避免出现悬空指针访问。
• 针对单线程场景下的索引更新逻辑，修复了极端情况下的内存对齐错误，这类错误仅在持续运行多日后才会触发，符合你的问题出现频率。

建议优先升级至5.23.37版本，虽然无法100%确认修复，但上述底层组件的稳定性修复覆盖了你的崩溃栈涉及的核心路径。

2. 外部进程操作导致问题的可能性 #

完全有可能，Chronicle Queue依赖内存映射文件实现高性能读写，若外部进程对其数据文件进行以下操作，可能触发这类崩溃：

• 文件系统级别的快照/备份工具：如rsync、tar或云厂商的自动快照服务，在备份过程中可能锁定或修改文件的内存映射区域，导致JVM访问已失效的内存地址。
• 磁盘清理/压缩工具：部分工具会对未被主动锁定的文件进行压缩或移动操作，破坏Chronicle Queue的文件结构，在关闭Appender时访问索引数据会触发内存错误。
• 系统级内存回收机制：部分Linux系统的oom-killer或内存管理工具，可能误将Chronicle Queue的内存映射区域标记为可回收，导致关闭阶段访问已释放的内存。
• 防病毒/安全扫描工具：实时扫描进程可能读取或修改Chronicle Queue的索引文件，干扰内存映射的正常访问，引发SIGSEGV。

这类外部操作导致的问题通常具有偶发性，且与运行时长相关，符合你遇到的场景。

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