Как проанализировать журнал сбоев в boot.oat?( 'LinkToDeath(): получатель должен быть не NULL')

Question

Сбой приложения происходит при переключении пользователя Android с владельца на гостя.

основные журналы сбоев см. ниже:

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. arm-linux-androideabi-addr2line -C -e../tmp/libaudioeffect_jni.so 00002595

   рамки / база / СМИ / JNI / audioeffect / android_media_AudioEffect.cpp: 355

2. arm-linux-androideabi-addr2line -C -e../tmp/libmedia.so 000943ed

   рамки / ау / СМИ / libmedia / AudioEffect.cpp: 88

3. arm-linux-androideabi-addr2line -C -e../tmp/libmedia.so 0009426f

   рамки / ау / СМИ / libmedia / AudioEffect.cpp: 158

   IInterface: asBinder (IEffect) -> linkToDeath (mIEffectClient);

4. oatdump

Вопрос:

• Это правильно для меня, чтобы сбросить файл овса?

• Это все четное число адресов oatdump (зачем показывать здесь 02affcd3? Это же нечетное число)

• Как мы можем вытащить файл овса, который был проанализирован в папке устройств Android?

• Что вы предлагаете по этому вопросу?

Answer 1

Не существует единого способа анализа аварийных дампов. Каждый из них уникален и требует индивидуального подхода. Тем не менее, есть один общий шаг - преобразование адресов обратной линии в строки / числа. Вы сделали это с addr2line, Это немного утомительно и сделать вещи проще, вы можете использовать ndk-stack, Это делает абсолютно то же самое, но более удобным способом.

Вернемся к аварии. как мы видим, проблема в коде фреймворка, а не в вашем приложении. На самом деле это утверждение, которое было брошено BpBinder::linkToDeath(), Я думаю, это своего рода ошибка в системе, и вы ничего не можете с этим поделать. Еще одна причина относиться к ней как к системной ошибке - это тот факт, что BpBinder метод был вызван из android::AudioEffect учебный класс. Фактическая реализация аудиоэффекта предоставляется поставщиком, и, вероятно, этот механизм связывания использовался для связи между общим кодом и реализацией для конкретного устройства. Такие реализации могут быть недостаточно хорошо протестированы или рассмотрены, поскольку над ним работает гораздо меньше людей, чем над общим кодом для нескольких устройств.

Чтобы выяснить, что это не связано с вашим кодом, создайте минимальное приложение, которое использует звуковые эффекты аналогично вашему, и попытайтесь воспроизвести проблему, переключаясь между пользователями.