Androidプログラム実行エラー「Process xxxx has died」原因検索
プログラムが削除された後、log分析をキャプチャします.次のヒントがあります.
"I/ActivityManager( 2212): Process com.seven.test (pid 2758) has died."
この言葉の意味は、私たちのプログラムのメインプロセスが死んだということです.これは私たちが望んでいるのではないに違いありません.では、このような間違いはどのように分析しますか.以下は私の分析過程です.
1.まず重要なロゴを見つけます
どうしてこのロゴを捕まえるのですか?これはプロセスから出なければなりません.このエラーといえば、このエラーは一般的にメモリスタックのオーバーフローによるもので、メモリスタックのオーバーフローの原因はJNIの呼び出しに大きくあり、私のテストプログラムでは確かにJNIが使用されています.この問題はC/C++で書かれたコードにあります.例えば、大きなスタック空間char[65535]を申請したり、C/C++でスタックメソッドを再帰的に呼び出したりして、コードに非論理的なエラーが発生する可能性もあるが、コード判断エラーや正常な投げ出し異常がないなどして、スタックオーバーフローなどを引き起こす.
2.分析方法
logを表示するだけでは具体的にどこが間違っているのか分からないので、呼び出したものを逆アセンブリする必要があります.soライブラリファイルは、C/C++メソッドがコンパイルされているためです.soライブラリファイルにあります.次の方法で逆アセンブリできます.
Android SourceCodeディレクトリの下にあります.
パス:
AndroidSourceCode/prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin
キー:
逆アセンブリに使用できるarm-eabi-objdumpツールがあります
端末での実行方法は次のとおりです.
./arm-eabi-objdump -dS mylib.so > mylib.dump
最後に、逆アセンブリ後のlibtpを開きます.dump、検索によりコードエラーアドレスが見つかりました:00008306.エラーアドレスによって、C/C++で具体的にどの方法がエラーになったかを知ることができます.
以上の手順はUbuntu 10.04の環境で行います.
"I/ActivityManager( 2212): Process com.seven.test (pid 2758) has died."
この言葉の意味は、私たちのプログラムのメインプロセスが死んだということです.これは私たちが望んでいるのではないに違いありません.では、このような間違いはどのように分析しますか.以下は私の分析過程です.
1.まず重要なロゴを見つけます
I/DEBUG ( 2104): pid: 2758, tid: 3374 >>> com.seven.test <<<
I/DEBUG ( 2104): signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 3128b000
I/DEBUG ( 2104): r0 0000006c r1 312873ff r2 00000001 r3 00000000
I/DEBUG ( 2104): r4 3128b001 r5 002625a0 r6 00000030 r7 31287444
I/DEBUG ( 2104): r8 4120bc36 r9 4120d264 10 412103d0 fp 4120bf18
I/DEBUG ( 2104): ip 4120d2dc sp 31287410 lr 41208297 pc 41208306 cpsr 20000030
I/DEBUG ( 2104): d0 6265726f7473202c d1 6d756e20646e6165
I/DEBUG ( 2104): d2 4a5f6e6f6d6d6f61 d3 6e6f6d6d6f436964
I/DEBUG ( 2104): d4 c1b9a500c1b5a500 d5 40e0000000000007
I/DEBUG ( 2104): d6 c1d80000ffffffe5 d7 7149f2ca00000000
I/DEBUG ( 2104): d8 0000000042f61800 d9 42f6180042f61800
I/DEBUG ( 2104): d10 446147ae2b09cae8 d11 00000000446147ae
I/DEBUG ( 2104): d12 0000000000000000 d13 0000000000000000
I/DEBUG ( 2104): d14 0000000000000000 d15 0000000000000000
I/DEBUG ( 2104): d16 7eb0fe582b07fb58 d17 4010000000000000
I/DEBUG ( 2104): d18 0000000000000000 d19 0000000000000000
I/DEBUG ( 2104): d20 3ff0000000000000 d21 8000000000000000
I/DEBUG ( 2104): d22 0000000000000000 d23 0000fd010000fd22
I/DEBUG ( 2104): d24 0000050000000520 d25 0000050000000520
I/DEBUG ( 2104): d26 0000050000000520 d27 0000050000000520
I/DEBUG ( 2104): d28 0000000000000000 d29 3ff0000000000000
I/DEBUG ( 2104): d30 0000000000000000 d31 3ff0000000000000
I/DEBUG ( 2104): scr 60000012
I/DEBUG ( 2104):
I/DEBUG ( 2104): #00 pc 00008306 /data/data/com.seven.test/files/mylib.so
I/DEBUG ( 2104): #01 pc 000083d4 /data/data/com.seven.test/files/mylib.so
I/DEBUG ( 2104):
I/DEBUG ( 2104): code around pc:
I/DEBUG ( 2104): 412082e4 447b4a0d 33184479 f7fa447a f04fecea
I/DEBUG ( 2104): 412082f4 e00930ff 280a3401 f804d103 20000c01
I/DEBUG ( 2104): 41208304 f804e002 e7e30c01 70212100 bf00bd70
I/DEBUG ( 2104): 41208314 0000222e 00003897 0000390a 4ff0e92d
I/DEBUG ( 2104): 41208324 81acf8df 91acf8df 6d84f5ad 468244f8
I/DEBUG ( 2104):
I/DEBUG ( 2104): code around lr:
I/DEBUG ( 2104): 41208274 22002c8c f44f9300 46136080 f7fa4629
I/DEBUG ( 2104): 41208284 2801ee5e d1074602 f10d4620 f7fa0197
I/DEBUG ( 2104): 41208294 f89dedba e00b0097 49094808 44784a09
I/DEBUG ( 2104): 412082a4 030cf110 447a4479 f7fa2003 2000ed0a
I/DEBUG ( 2104): 412082b4 bd30b027 000f4240 fff0bdc0 00002272
I/DEBUG ( 2104):
I/DEBUG ( 2104): stack:
I/DEBUG ( 2104): 312873d0 00000000
I/DEBUG ( 2104): 312873d4 00000000
I/DEBUG ( 2104): 312873d8 00000000
I/DEBUG ( 2104): 312873dc 00000000
I/DEBUG ( 2104): 312873e0 00000000
I/DEBUG ( 2104): 312873e4 00000000
I/DEBUG ( 2104): 312873e8 00000000
I/DEBUG ( 2104): 312873ec 00000000
I/DEBUG ( 2104): 312873f0 00000000
I/DEBUG ( 2104): 312873f4 00000002
I/DEBUG ( 2104): 312873f8 0007a11d
I/DEBUG ( 2104): 312873fc 6cd0b0be
I/DEBUG ( 2104): 31287400 4120bb83 /data/data/com.seven.test/files/mylib.so
I/DEBUG ( 2104): 31287404 3128b000
I/DEBUG ( 2104): 31287408 df002777
I/DEBUG ( 2104): 3128740c e3a070ad
I/DEBUG ( 2104): #00 31287410 4120bb83 /data/data/com.seven.test/files/mylib.so
I/DEBUG ( 2104): 31287414 31287644
I/DEBUG ( 2104): 31287418 4120a53c /data/data/com.seven.test/files/mylib.so
I/DEBUG ( 2104): 3128741c 412083d9 /data/data/com.seven.test/files/mylib.so
I/DEBUG ( 2104): #01 31287420 31287444
I/DEBUG ( 2104): 31287424 00000001
I/DEBUG ( 2104): 31287428 4120bb83 /data/data/com.seven.test/files/mylib.so
I/DEBUG ( 2104): 3128742c 00000007
I/DEBUG ( 2104): 31287430 00000000
I/DEBUG ( 2104): 31287434 31287b00
I/DEBUG ( 2104): 31287438 002625a0
I/DEBUG ( 2104): 3128743c 4120a53c /data/data/com.seven.test/files/mylib.so
I/DEBUG ( 2104): 31287440 4120bb83 /data/data/com.seven.test/files/mylib.so
I/DEBUG ( 2104): 31287444 00000000
I/DEBUG ( 2104): 31287448 00000000
I/DEBUG ( 2104): 3128744c 00000000
I/DEBUG ( 2104): 31287450 00000000
I/DEBUG ( 2104): 31287454 00000000
I/DEBUG ( 2104): 31287458 00000000
I/DEBUG ( 2104): 3128745c 00000000
I/DEBUG ( 2104): 31287460 00000000
I/DEBUG ( 2104): 31287464 00000000
どうしてこのロゴを捕まえるのですか?これはプロセスから出なければなりません.このエラーといえば、このエラーは一般的にメモリスタックのオーバーフローによるもので、メモリスタックのオーバーフローの原因はJNIの呼び出しに大きくあり、私のテストプログラムでは確かにJNIが使用されています.この問題はC/C++で書かれたコードにあります.例えば、大きなスタック空間char[65535]を申請したり、C/C++でスタックメソッドを再帰的に呼び出したりして、コードに非論理的なエラーが発生する可能性もあるが、コード判断エラーや正常な投げ出し異常がないなどして、スタックオーバーフローなどを引き起こす.
2.分析方法
logを表示するだけでは具体的にどこが間違っているのか分からないので、呼び出したものを逆アセンブリする必要があります.soライブラリファイルは、C/C++メソッドがコンパイルされているためです.soライブラリファイルにあります.次の方法で逆アセンブリできます.
Android SourceCodeディレクトリの下にあります.
パス:
AndroidSourceCode/prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin
キー:
逆アセンブリに使用できるarm-eabi-objdumpツールがあります
端末での実行方法は次のとおりです.
./arm-eabi-objdump -dS mylib.so > mylib.dump
最後に、逆アセンブリ後のlibtpを開きます.dump、検索によりコードエラーアドレスが見つかりました:00008306.エラーアドレスによって、C/C++で具体的にどの方法がエラーになったかを知ることができます.
以上の手順はUbuntu 10.04の環境で行います.