SEGV問題のデバッグに役立つ必要がありますか？ - Android NDK

Question

Android用ソースコードの大きな本体を持つライブラリを構築しています。ライブラリは、Linux x86用にコンパイルされていればうまく動作します。スタンドアローンのツールチェーンで構築しています。これまで他の図書館でもこれまで成功していたので、セットアップがうまくいくと思います。とにかく、コンパイルとリンクはすべていいですが、結果として得られる共有ライブラリをロードすると、SEGVが得られます。私はaddr2lineにを使用している場合は、私がこの情報を取得

03-23 23:37:14.213: I/DEBUG(28): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 
03-23 23:37:14.213: I/DEBUG(28): Build fingerprint: 'generic/sdk/generic/:2.1-update1/ECLAIR/35983:eng/test-keys' 
03-23 23:37:14.224: I/DEBUG(28): pid: 332, tid: 332 >>> com.example.hellojni <<< 
03-23 23:37:14.224: I/DEBUG(28): signal 11 (SIGSEGV), fault addr 00000000 
03-23 23:37:14.224: I/DEBUG(28): r0 00000000 r1 00000000 r2 80808080 r3 00000000 
03-23 23:37:14.224: I/DEBUG(28): r4 00000000 r5 bea8154c r6 bea81600 r7 00000000 
03-23 23:37:14.224: I/DEBUG(28): r8 bea81820 r9 41971894 10 00000354 fp bea814fc 
03-23 23:37:14.224: I/DEBUG(28): ip 80a81058 sp bea814c0 lr 80a63cd8 pc afe0e7c8 cpsr 40000010 
03-23 23:37:14.313: I/DEBUG(28):   #00 pc 0000e7c8 /system/lib/libc.so 
03-23 23:37:14.313: I/DEBUG(28):   #01 pc 00063cd4 /data/data/com.example.hellojni/lib/libgnustl_shared.so 
03-23 23:37:14.323: I/DEBUG(28): code around pc: 
03-23 23:37:14.323: I/DEBUG(28): afe0e7b8 e31c0003 1afffff6 e1a00002 e59f20d8 
03-23 23:37:14.323: I/DEBUG(28): afe0e7c8 e490c004 e0433000 f5d0f040 e04c13a2 
03-23 23:37:14.323: I/DEBUG(28): afe0e7d8 e0011002 e1d1100c 0490c004 1a000022 
03-23 23:37:14.323: I/DEBUG(28): code around lr: 
03-23 23:37:14.323: I/DEBUG(28): 80a63cc8 e1a05000 e1a00001 e1a04001 ebff27d0 
03-23 23:37:14.323: I/DEBUG(28): 80a63cd8 e1a01004 e1a02000 e1a00005 e8bd4070 
03-23 23:37:14.323: I/DEBUG(28): 80a63ce8 eaffffa0 e590c000 e92d45f0 e51ce00c 
03-23 23:37:14.323: I/DEBUG(28): stack: 
03-23 23:37:14.323: I/DEBUG(28):  bea81480 001479d0 [heap] 
03-23 23:37:14.323: I/DEBUG(28):  bea81484 bea81820 [stack] 
03-23 23:37:14.323: I/DEBUG(28):  bea81488 41971894 /dev/ashmem/dalvik-LinearAlloc (deleted) 
03-23 23:37:14.323: I/DEBUG(28):  bea8148c 00000354 
03-23 23:37:14.334: I/DEBUG(28):  bea81490 bea814fc [stack] 
03-23 23:37:14.334: I/DEBUG(28):  bea81494 00147a24 [heap] 
03-23 23:37:14.334: I/DEBUG(28):  bea81498 00000006 
03-23 23:37:14.334: I/DEBUG(28):  bea8149c 80a63b58 /data/data/com.example.hellojni/lib/libgnustl_shared.so 
03-23 23:37:14.334: I/DEBUG(28):  bea814a0 00000006 
03-23 23:37:14.334: I/DEBUG(28):  bea814a4 bea81548 [stack] 
03-23 23:37:14.334: I/DEBUG(28):  bea814a8 80a82110 
03-23 23:37:14.334: I/DEBUG(28):  bea814ac 00000000 
03-23 23:37:14.334: I/DEBUG(28):  bea814b0 bea81820 [stack] 
03-23 23:37:14.334: I/DEBUG(28):  bea814b4 80a63bcc /data/data/com.example.hellojni/lib/libgnustl_shared.so 
03-23 23:37:14.334: I/DEBUG(28):  bea814b8 df002777 
03-23 23:37:14.334: I/DEBUG(28):  bea814bc e3a070ad 
03-23 23:37:14.344: I/DEBUG(28): #00 bea814c0 bea814d4 [stack] 
03-23 23:37:14.344: I/DEBUG(28):  bea814c4 00000000 
03-23 23:37:14.344: I/DEBUG(28): #01 bea814c8 bea81548 [stack] 
03-23 23:37:14.344: I/DEBUG(28):  bea814cc bea81548 [stack] 
03-23 23:37:14.344: I/DEBUG(28):  bea814d0 bea81600 [stack] 
03-23 23:37:14.344: I/DEBUG(28):  bea814d4 8131f228 /data/data/com.example.hellojni/lib/libsharedB.so 
03-23 23:37:14.344: I/DEBUG(28):  bea814d8 afe39190 /system/lib/libc.so 
03-23 23:37:14.344: I/DEBUG(28):  bea814dc bea8152c [stack] 
03-23 23:37:14.344: I/DEBUG(28):  bea814e0 001479a0 [heap] 
03-23 23:37:14.344: I/DEBUG(28):  bea814e4 bea81548 [stack] 
03-23 23:37:14.344: I/DEBUG(28):  bea814e8 80a8211c 
03-23 23:37:14.344: I/DEBUG(28):  bea814ec 001479a0 [heap] 
03-23 23:37:14.344: I/DEBUG(28):  bea814f0 bea81548 [stack] 
03-23 23:37:14.344: I/DEBUG(28):  bea814f4 bea81548 [stack] 
03-23 23:37:14.344: I/DEBUG(28):  bea814f8 bea8151c [stack] 
03-23 23:37:14.344: I/DEBUG(28):  bea814fc 8131eb8c /data/data/com.example.hellojni/lib/libsharedB.so 
03-23 23:37:14.344: I/DEBUG(28):  bea81500 bea8152c [stack] 
03-23 23:37:14.344: I/DEBUG(28):  bea81504 0000272e 
03-23 23:37:14.344: I/DEBUG(28):  bea81508 80a82124 
03-23 23:37:14.344: I/DEBUG(28):  bea8150c 80a8211c 
03-23 23:37:14.884: D/Zygote(30): Process 332 terminated by signal (11) 
03-23 23:37:14.893: I/ActivityManager(52): Process com.example.hellojni (pid 332) has died. 
03-23 23:37:14.966: I/UsageStats(52): Unexpected resume of com.android.launcher while already resumed in com.example.hellojni 

：これは私が取得するトレースである

android-linux-addr2line.exe -C -f -e libc.so 0000e7c8 
strlen 
??:0 

android-linux-addr2line.exe -C -f -e libgnustl_shared.so 00063cd4 
std::string::operator=(char const*) 
??:0 

[OK]を、ので、文字列の静的割り当てと間違って何かがあるかもしれません。それは失敗の署名を説明するでしょう。ですから、どのようにソースコード内でこれが起こっているのか把握するにはどうすればよいですか？次のステップに進んで問題の原因となった課題がどこにあったのかを確認するにはどうすればよいですか？ここでも、これはソースコードの大きな本体であり、文字列の多くの静的割り当てがあるようです。私はそれを絞り込む必要があります。

Answer 1

トレースの上部は、（これは通常、私が見ている部分だけである）助けにはならなかったので、[OK]を：

：私はラインがこれを行ご覧さらにダウン

03-23  23:37:14.313: I/DEBUG(28):   #00 pc 0000e7c8 /system/lib/libc.so 
03-23  23:37:14.313: I/DEBUG(28):   #01 pc 00063cd4 /data/data/com.example.hellojni/lib/libgnustl_shared.so 

が、

03-23 23:37:14.344: I/DEBUG(28):  bea814d4 8131f228 /data/data/com.example.hellojni/lib/libsharedB.so 

これでaddr2lineを使用し、最近libsharedB.soの関数がスタックにあったことを示す他の行は、私の答えが得られます。唯一の追加のトリックは8131f228で、私が入力する必要があるアドレスではありませんでした。代わりに、私は0131f228に入る必要があった。 80000000はライブラリのベースアドレスで、残りはその領域内のアドレスです。