Android 2.3.4 に付属する Amazon Kindle Fire の問題を解決するのにいくつかの困難があり、クラッシュは SIGSERV であり、常に再現するとは限りません。
アプリ自体はネイティブ ゲームであり、いくつかの時点でクラッシュします。ログ ステートメントを介して、クラッシュの正確な原因を特定することは困難です。セーブゲームでゲームの状態をキャプチャして、面倒なセクションを復元して実行し続けることができました.
この問題は、Proguard が有効になっている場合にのみ再現されます。さまざまな機能を無効にする Proguard のさまざまな構成を試しました。以下はproguardで使用されており、問題に違いはありません:
-keepclasseswithmembers class *{
native <methods>;
}
-keepclasseswithmembers class * {
*** *Callback(...);
}
-dontshrink
-dontoptimize
-dontpreverify
-keep class javax.** { *; }
-keep class java.** { *; }
-keep class org.** { *; }
-keep class android.** { *; }
-keep class com.** { *; }
-dontobfuscate を追加すると問題が解決するようですが、効果がランダムであるため、100% 確認することはできません。
スタック トレースは次のとおりです。
I/DEBUG (23231): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG (23231): Build fingerprint: 'generic/blaze/blaze:2.3.4 GINGERBREAD/6.3.1_user_4107720:user/release-keys'
I/DEBUG (23231): pid: 23238, tid: 23409 >>> mypackage <<<
I/DEBUG (23231): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
I/DEBUG (23231): r0 00000000 r1 0045ae68 r2 00000fc0 r3 006f003b
I/DEBUG (23231): r4 003b0059 r5 00040013 r6 fff60000 r7 0004fff5
I/DEBUG (23231): r8 00080009 r9 0046d350 10 00100000 fp 00000001
I/DEBUG (23231): ip 00120008 sp 48c2ee24 lr 00070013 pc afd0cfe0 cpsr 20000110
I/DEBUG (23231): d0 0000001900000110 d1 be94da8200000000
I/DEBUG (23231): d2 bfd180bc00000000 d3 3feec709dc3a0300
I/DEBUG (23231): d4 be86935e00000000 d5 bfd5a7f8c70233a6
I/DEBUG (23231): d6 458000009eb93fdb d7 00000b9a00000b9a
I/DEBUG (23231): d8 00000000103a3c9d d9 0000000000000000
I/DEBUG (23231): d10 0000000000000000 d11 0000000000000000
I/DEBUG (23231): d12 0000000000000000 d13 0000000000000000
I/DEBUG (23231): d14 0000000000000000 d15 0000000000000000
I/DEBUG (23231): d16 3fe7356a68b6af7e d17 3ff0000000000000
I/DEBUG (23231): d18 be607fc1c458778e d19 bfa7cc5f02a59422
I/DEBUG (23231): d20 4000000000000000 d21 3f114aff86ff44bc
I/DEBUG (23231): d22 bebbaaeb53350f0d d23 bfd48eb6ede7d000
I/DEBUG (23231): d24 3e66376972bea4d0 d25 3fd193d7807f5e77
I/DEBUG (23231): d26 3ff4000000000000 d27 bfa7cc5f02a59424
I/DEBUG (23231): d28 c002b4ff18e04675 d29 bfd48eb70ee75389
I/DEBUG (23231): d30 3c6ad5a68fb54afb d31 be607fc1c4800000
I/DEBUG (23231): scr 80000012
I/DEBUG (23231):
I/DEBUG (23231): #00 pc 0000cfe0 /system/lib/libc.so
I/DEBUG (23231): #01 lr 00070013 <unknown>
I/DEBUG (23231):
I/DEBUG (23231): code around pc:
I/DEBUG (23231): afd0cfc0 24c04001 24c05001 e2522020 ba000005
I/DEBUG (23231): afd0cfd0 f5d1f060 f5d1f080 e8b151f8 e2522020
I/DEBUG (23231): afd0cfe0 e8a051f8 aafffffa e2922020 0a00000c
I/DEBUG (23231): afd0cff0 e1b0ce02 28b10078 48b10180 28a00078
I/DEBUG (23231): afd0d000 48a00180 e1b0cf02 24913004 40d140b2
I/DEBUG (23231):
I/DEBUG (23231): code around lr:
I/DEBUG (23231): 0006fff0 00000000 00000000 00000000 00000000
I/DEBUG (23231): 00070000 00000000 00000000 00000000 00000000
I/DEBUG (23231): 00070010 00000000 00000000 00000000 00000000
I/DEBUG (23231): 00070020 00000000 00000000 00000000 00000000
I/DEBUG (23231): 00070030 00000000 00000000 00000000 00000000
I/DEBUG (23231):
I/DEBUG (23231): stack:
I/DEBUG (23231): 48c2ede4 00000000
I/DEBUG (23231): 48c2ede8 00000000
I/DEBUG (23231): 48c2edec 00000000
I/DEBUG (23231): 48c2edf0 00000000
I/DEBUG (23231): 48c2edf4 00000000
I/DEBUG (23231): 48c2edf8 00000000
I/DEBUG (23231): 48c2edfc 00000000
I/DEBUG (23231): 48c2ee00 00000000
I/DEBUG (23231): 48c2ee04 00000000
I/DEBUG (23231): 48c2ee08 00000000
I/DEBUG (23231): 48c2ee0c 00000000
I/DEBUG (23231): 48c2ee10 002275c4
I/DEBUG (23231): 48c2ee14 00000001
I/DEBUG (23231): 48c2ee18 df002777
I/DEBUG (23231): 48c2ee1c e3a070ad
I/DEBUG (23231): 48c2ee20 48c2ee5c
I/DEBUG (23231): #00 48c2ee24 002275a0
I/DEBUG (23231): 48c2ee28 00001000
I/DEBUG (23231): 48c2ee2c 48c2ee5c
I/DEBUG (23231): 48c2ee30 00001000
I/DEBUG (23231): 48c2ee34 a811cda9 /system/lib/libutils.so
I/DEBUG (23231): 48c2ee38 00000000
I/DEBUG (23231): 48c2ee3c 81004f45 /system/lib/libOpenSLES.so
I/DEBUG (23231): 48c2ee40 00000000
I/DEBUG (23231): 48c2ee44 002275a0
I/DEBUG (23231): 48c2ee48 00227eb8
I/DEBUG (23231): 48c2ee4c 00000800
I/DEBUG (23231): 48c2ee50 48c2ee5c
I/DEBUG (23231): 48c2ee54 a903181b /system/lib/libmedia.so
I/DEBUG (23231): 48c2ee58 00000000
I/DEBUG (23231): 48c2ee5c 00000000
I/DEBUG (23231): 48c2ee60 00000001
I/DEBUG (23231): 48c2ee64 00000001
I/DEBUG (23231): 48c2ee68 00000800
デバッグ情報を取得するために、proguard をデバッグ モードで有効にし、デバッグ シンボルを有効にして gdb を実行しました。クラッシュが発生すると、gdb を介して、フレームのリターン ポインターが上書きされるため、バックトレースが破棄されます。
addr2line を使用すると、メモリ参照は memcpy でクラッシュしたことを示しています。gdb を少し調べてみると、memcpy の最初の引数に NULL ポインターが渡されていることがわかります。
この問題の根源を見つけるために多くのことを試みましたが、memcpy 関数を独自の特注の関数に置き換えて、赤字の問題をキャッチしようとしました。ただし、ARM ポインター演算でのリダイレクトでいくつかの問題が発生していました。
lr レジスタではなく、スタック上のリターン ポインタが JITed コードを指しているようです。memcpy を呼び出すのは私のネイティブ コードではありません。
スタックを手動で調べると、ネイティブ コードを指しているようには見えません。
問題を特定するためのより有用な情報を取得すること、または memcpy で置換機能を実行することについての提案はありますか? または、ネイティブ クラッシュから有用な dalvik スタック トレースを取得します。