boot.oatのクラッシュログを分析する方法（ 'linkToDeath（）：受信者はNULLでない必要があります'）

Question

Androidユーザーからオーナーに切り替える際にAPPクラッシュが発生します。

コアクラッシュログは、以下参照：

08-12 23:46:03.724 27197 27197 F libc : Fatal signal 6 (SIGABRT), code -6 in tid 27197 (com.dolby) 
08-12 23:46:03.855 312 312 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 
08-12 23:46:03.888 312 312 F DEBUG : Build fingerprint: 'Lenovo/TB-X103F/TB-X103F:6.0.1/LenovoTB-X103F/TB-X103F_S000013_160813_ROW:user/release-keys' 
08-12 23:46:03.889 312 312 F DEBUG : Revision: '0' 
08-12 23:46:03.889 312 312 F DEBUG : ABI: 'arm' 
08-12 23:46:03.893 312 312 F DEBUG : pid: 27197, tid: 27197, name: com.dolby >>> com.dolby <<< 
08-12 23:46:03.893 312 312 F DEBUG : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- 
08-12 23:46:03.940 312 312 F DEBUG : Abort message: 'linkToDeath(): recipient must be non-NULL' 
08-12 23:46:03.941 312 312 F DEBUG :  r0 00000000 r1 00006a3d r2 00000006 r3 b6fadb7c 
08-12 23:46:03.942 312 312 F DEBUG :  r4 b6fadb84 r5 b6fadb34 r6 00000002 r7 0000010c 
08-12 23:46:03.942 312 312 F DEBUG :  r8 00000000 r9 00000000 sl 00000000 fp b7226ccc 
08-12 23:46:03.942 312 312 F DEBUG :  ip 00000006 sp be9062f0 lr b6d2ed85 pc b6d31174 cpsr 400f0010 
08-12 23:46:03.993 312 312 F DEBUG : 
08-12 23:46:03.993 312 312 F DEBUG : backtrace: 
08-12 23:46:03.993 312 312 F DEBUG :  #00 pc 00044174 /system/lib/libc.so (tgkill+12) 
08-12 23:46:03.994 312 312 F DEBUG :  #01 pc 00041d81 /system/lib/libc.so (pthread_kill+32) 
08-12 23:46:03.994 312 312 F DEBUG :  #02 pc 0001ba2f /system/lib/libc.so (raise+10) 
08-12 23:46:03.995 312 312 F DEBUG :  #03 pc 00018be1 /system/lib/libc.so (__libc_android_abort+34) 
08-12 23:46:03.995 312 312 F DEBUG :  #04 pc 000167a8 /system/lib/libc.so (abort+4) 
08-12 23:46:03.995 312 312 F DEBUG :  #05 pc 0000864b /system/lib/libcutils.so (__android_log_assert+86) 
08-12 23:46:03.996 312 312 F DEBUG :  #06 pc 0001a823 /system/lib/libbinder.so (_ZN7android8BpBinder11linkToDeathERKNS_2spINS_7IBinder14DeathRecipientEEEPvj+86) 
08-12 23:46:03.997 312 312 F DEBUG :  #07 pc 0009426f /system/lib/libmedia.so (_ZN7android11AudioEffect3setEPK13effect_uuid_sS3_iPFviPvS4_ES4_ii+530) 
08-12 23:46:03.997 312 312 F DEBUG :  #08 pc 000943ed /system/lib/libmedia.so (_ZN7android11AudioEffectC2EPKcRKNS_8String16ES2_iPFviPvS6_ES6_ii+156) 
08-12 23:46:03.998 312 312 F DEBUG :  #09 pc 00002595 /system/lib/libaudioeffect_jni.so 
08-12 23:46:03.998 312 312 F DEBUG :  #10 pc 02affcd3 /system/framework/arm/boot.oat (offset 0x1ef2000) 

マイ分析：

1. をアームのLinux-androideabi-addr2lineに-C -e ../tmp/libaudioeffect_jni.so 00002595

   frameworks/base/media/jni/audioeffect/android_media_AudioEffect.cpp：355

2. アームのLinux-androideabi-addr2lineに-C -e ../tmp/libmedia.so 000943ed

   フレームワーク/ AV /メディア/ libmedia/AudioEffect.cpp：88

3. アームのLinux -androideabi-addr2lineに-C -e ../tmp/libmedia.so 0009426f

   フレームワーク/ AV /メディア/ libmedia/AudioEffect.cpp：158

   メソッドはIInterface：asBinder（はIEffect） - > linkToDeath（ mIEffectClient）;

4. oatdump

質問：私はオート麦ファイルをダンプするため

• それは正しいですか？

• それはoatdumpアドレスのすべて偶数だ（なぜ私をここ02affcd3示して？それは奇数同じです）

• はどのように我々は、Androidデバイスのフォルダの下に解析されたオート麦ファイルを引くことができますか？

• この問題に関するご意見はありますか？

Answer 1

クラッシュダンプを分析する単一の方法はありません。それぞれはユニークで、個別の治療が必要です。それにもかかわらず、バックトレースアドレスをライン/数値に変換する共通のステップが1つあります。あなたはaddr2lineでそれをしました。ちょっと面倒で、使いやすくするためにndk-stackを使用してください。それは絶対に同じですが、より便利な方法で行います。

クラッシュする可能性があります。問題はフレームワークコードのどこかにあり、アプリではないことがわかります。実際にはこれはBpBinder::linkToDeath()によってスローされたアサーションです。私はこれがシステムの一種のバグだと思っていて、あなたはそれで何もできません。これをシステムバグとして扱うもう一つの理由は、BpBinderのメソッドがandroid::AudioEffectクラスから呼び出されたという事実です。実際のオーディオエフェクトの実装はベンダーによって提供されており、一般的なコードとデバイス固有の実装の間の通信にバインダーが使用されていた可能性があります。そのような実装は、一般的なクロスデバイスコードよりもはるかに少ない人が作業するため、十分にテストされたりレビューされたりすることはありません。

あなたのコードには関係ないことを理解するには、あなたと同様の方法でオーディオエフェクトを使用する最小限のアプリケーションを作成し、ユーザー間で切り替えて問題を再現してみてください。