第27回横浜Androidプラットフォーム部勉強会発表資料です

1. 横浜 Android プラットフォーム部
第 27 回勉強会
Android のデバッグ小ネタ
2012/12/22
@l_b__

2. リブートバグ
●
端末のリブート、困りますよね
●
リブートの原因は HW のこともあるけれど、
大抵 SW
●
SW 要因の場合、大きな原因は 2 つでした

3. リブート要因
●
フレームワーク部分処理で無限ループ / デッ
ドロックで処理が止まり、 Watchdog から
リブート
●
Init で起動される System 権限のサーバ類が例
外で落ちてリブート

4. Watchdog からリブート
●
どこで処理が止まっているかを探しましょう
●
ANR を出していることが多いので、その辺り
の時刻のログを取得
●
bugreport を出力してチェック

5. bugreport
●
端末内の様々な状態をまとめて取得するコマンド
●
# adb bugreport で標準出力に出力される
– リダイレクトしてファイルに保存しましょう
●
内部処理として、 dumpstate サービスに接続して、情
報を取得
●
JelleyBean ではソースは
– bugreport frameworks/base/cmds/bugreport
– dumpstate frameworks/native/cmds/dumpstate

6. bugreport はどんな情報が ?
●
カーネルから取得した CPU やメモリの情報
●
ログ (main/events/system/radio) を一通り
●
ANR のトレース
●
ネットワークの情報
●
システム設定 DB の内容
●
システムプロパティ
●
ファイルシステムの状態
●
パッケージの情報
●
Binder の情報
●
Framework サービスの情報
●
実行中アプリのアクティビティ、サービス、プロバイダの情報

7. 問題箇所を探すには ?
●
VM TRACES JUST NOW の箇所を確認しま
しょう
●
Bugreport 実行時や ANR 発生した時の VM ス
タックトレースを出力
●
問題が発生していた時の実行メソッドを特定
できる

8. VM TRACES JUST NOW
●
------ VM TRACES JUST NOW (/data/anr/traces.txt.bugreport: 2012-08-26 06:35:25) ------
●
----- pid 124 at 2012-08-26 06:35:23 -----
●
Cmd line: /system/bin/surfaceflinger
●
"surfaceflinger" sysTid=124
●
#00 pc 0000cb60 /system/lib/libc.so (__ioctl+8)
●
#01 pc 00027f95 /system/lib/libc.so (ioctl+16)
●
#02 pc 00016bfd /system/lib/libbinder.so (android::IPCThreadState::talkWithDriver(bool)
+124)
●
#03 pc 000173af /system/lib/libbinder.so (android::IPCThreadState::joinThreadPool(bool)
+154)
●
#04 pc 000007ed /system/bin/surfaceflinger

9. VM TRACES JUST NOW
●
----- pid 25855 at 2012-08-26 06:35:25 -----
●
Cmd line: jp.r246.twicca
●
"AsyncTask #5" prio=5 tid=15 WAIT
●
| group="main" sCount=1 dsCount=0 obj=0x41d56710 self=0x662a45e0
●
| sysTid=25883 nice=10 sched=0/0 cgrp=apps/bg_non_interactive handle=1714047536
●
| schedstat=( 686456000 421807000 1632 ) utm=58 stm=10 core=0
●
at java.lang.Object.wait(Native Method)
●
- waiting on <0x41d44670> (a java.lang.VMThread) held by tid=15 (AsyncTask #5)
●
at java.lang.Thread.parkFor(Thread.java:1231)
●
at sun.misc.Unsafe.park(Unsafe.java:323)
●
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:157)
●
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2022)
●
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:413)
●
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1009)
●
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1069)
●
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
●
at java.lang.Thread.run(Thread.java:856)

10. 問題箇所を探すには ?
●
赤丸の箇所がダンプ取得時のプロセスが実行
していたメソッド
●
想定される処理待ち以外で止まっているプロ
セスがないかをチェック

11. 例外でリブート
●
logcat で例外発生時のスタックトレースを確
認
●
Java の場合は素直にスタックトレースを見れ
ば大体分かります
●
Native の場合は ...

12. Native Stacktrace の例
●
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
●
Build fingerprint: ‘generic/myboard_xxx/xxx/myplatform:2.1/ERD79/eng.arunks.20100726.14330
●
8:eng/test-keys’
●
pid: 1138, tid: 1138 >>> /system/bin/bluetoothd <<<
●
signal 11 (SIGSEGV), fault addr deadbaad
●
r0 00000000 r1 afe13369 r2 00000027 r3 00000054
●
r4 afe3ae08 r5 00000000 r6 00000000 r7 0000a000
●
r8 00000000 r9 00000000 10 00000000 fp 00000000
●
ip 00002ed8 sp bec782d8 lr deadbaad pc afe10a20 cpsr 60000030
●
#00 pc 00010a20 /system/lib/libc.so
●
#01 pc 0000b332 /system/lib/libc.so
●
#02 pc 0000ca62 /system/lib/bluez-plugin/audio.so
●
#03 pc 0000d1ce /system/lib/bluez-plugin/audio.so
●
#04 pc 0000e0ba /system/lib/bluez-plugin/audio.so

13. Native Stacktrace の例
●
#05 pc 0002f9a2 /system/lib/libbluetoothd.so
●
#06 pc 00026806 /system/lib/libbluetoothd.so
●
#07 pc 00026986 /system/lib/libbluetoothd.so
●
#08 pc 0002800c /system/lib/libbluetoothd.so
●
#09 pc 00028b72 /system/lib/libbluetoothd.so
●
#10 pc 0001891a /system/lib/libbluetoothd.so
●
#11 pc 0000c228 /system/lib/libc.so
●
code around pc:
●
afe10a10 f8442001 4798000c e054f8df 26002227
●
afe10a20 2000f88e ef2cf7fb f7fd2106 f04fe80a
●
afe10a30 91035180 460aa901 96012006 f7fc9602
●
code around lr:
●
...

14. 発生箇所を特定する
●
#00 pc 00010a20 /system/lib/libc.so
の箇所から、 libc.so の 0x00010a20 にて
signal 11 (SIGSEGV), fault addr deadbaad
が発生していることが分かります

15. 発生箇所を特定する
●
addr2line でどの関数で発生しているかを
チェック
●
JellyBean の場合、
– prebuilts/gcc/linux-x86/arm/arm-eabi-
4.6/bin/arm-eabi-addr2line

16. 発生箇所を特定する
●
arm-eabi-addr2line -f -e (path to libc.so)
0x00010a20
●
これで発生関数が特定できます
●
out/target/product/(Board name)/symbols 以
下のデバッグシンボル付きライブラリを指
定すれば発生行まで特定できます
●
後はスタックを上にたどれば作成した箇所の
どこで問題が発生しているか特定できます

17. まとめ
●
ログが取れれば以上の方法で原因追跡できま
す
●
大体リブートバグの 9 割くらいはこれで追え
るかな
●
一番難しいのはバグを再現してログを取るこ
とです
以上