Android JNI IndirectReferenceTable崩溃问题修复求助

咱们先把你提供的崩溃调用栈整理出来，方便分析：

#00 pc 000000000006a548 /system/lib64/libc.so (tgkill+8)
#01 pc 0000000000067cd8 /system/lib64/libc.so (pthread_kill+68)
#02 pc 0000000000024b78 /system/lib64/libc.so (raise+28)
#03 pc 000000000001f318 /system/lib64/libc.so (abort+60)
#04 pc 000000000043471c /system/lib64/libart.so (_ZN3art7Runtime5AbortEv+324)
#05 pc 0000000000137224 /system/lib64/libart.so (_ZN3art10LogMessageD2Ev+3136)
#06 pc 0000000000131cc8 /system/lib64/libart.so (_ZN3art7BarrierD2Ev+296)

调用栈核心分析 #

从栈的层级可以看出，这不是普通的应用层崩溃，而是ART虚拟机内部触发的主动进程终止：

• 最上层的tgkill/pthread_kill是Linux系统级的线程终止调用，只是最终执行崩溃的“执行者”，不是问题根源。
• 往上到abort()是进程终止的触发点，这里是ART虚拟机的Runtime::Abort()主动调用的，说明虚拟机内部检测到了致命错误。
• 关键线索在art::LogMessage的析构函数（_ZN3art10LogMessageD2Ev）：这意味着在输出错误日志的过程中触发了断言失败或致命错误，进而触发abort。
• 最接近问题源头的是art::Barrier的析构函数（_ZN3art7BarrierD2Ev）：Barrier是ART用来做线程同步的屏障类，析构时出问题，大概率是同步屏障的使用违反了线程安全规则。

具体排查方向 #

1. 检查JNI/底层线程操作
   如果你的应用或依赖的第三方SDK有JNI代码，或者直接调用了ART相关的底层API，重点排查Barrier类的使用是否合规：比如是否在屏障还有线程等待的情况下就提前析构了，或者析构操作的线程状态不符合要求。

2. 排查线程竞态条件
   多线程场景下，要确认是否存在多个线程同时操作同一个Barrier实例的情况，比如一个线程在等待屏障，另一个线程却提前释放了这个实例，这种竞态很容易触发虚拟机内部的错误。

3. ART版本兼容性验证
   尝试在不同Android版本的设备上复现崩溃：如果只在特定版本出现，大概率是对应版本ART虚拟机的已知bug。这种情况下可以尝试调整线程同步逻辑（比如用Java层的CountDownLatch替代底层的Barrier）来规避。

4. 开启ART调试日志
   通过adb命令开启ART的 verbose 日志：

   adb shell setprop debug.art.log.level verbose
   

   然后复现崩溃，获取更详细的ART内部日志，LogMessage输出的具体错误信息能直接帮你定位问题的核心。

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