SlideShare a Scribd company logo

Android デバッグ小ネタ

•Download as ODP, PDF•
•
L
l_b__

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

1 of 17
横浜 Android プラットフォーム部 第 27 回勉強会 Android のデバッグ小ネタ 2012/12/22 @l_b__
リブートバグ ● 端末のリブート、困りますよね ● リブートの原因は HW のこともあるけれど、 大抵 SW ● SW 要因の場合、大きな原因は 2 つでした
リブート要因 ● フレームワーク部分処理で無限ループ / デッ ドロックで処理が止まり、 Watchdog から リブート ● Init で起動される System 権限のサーバ類が例 外で落ちてリブート
Watchdog からリブート ● どこで処理が止まっているかを探しましょう ● ANR を出していることが多いので、��の辺り の時刻のログを取得 ● bugreport を出力してチェック
bugreport ● 端末内の様々な状態をまとめて取得するコマンド ● # adb bugreport で標準出力に出力される – リダイレクトしてファイルに保存しましょう ● 内部処理として、 dumpstate サービスに接続して、情 報を取得 ● JelleyBean ではソースは – bugreport 　 frameworks/base/cmds/bugreport – dumpstate 　 frameworks/native/cmds/dumpstate
bugreport はどんな情報が ? ● カーネルから取得した CPU やメモリの情報 ● ログ (main/events/system/radio) を一通り ● ANR のトレース ● ネットワークの情報 ● システム設定 DB の内容 ● システムプロパティ ● ファイルシステムの状態 ● パッケージの情報 ● Binder の情報 ● Framework サービスの情報 ● 実行中アプリのアクティビティ、サービス、プロバイダの情報
問題箇所を探すには ? ● VM TRACES JUST NOW の箇所を確認しま しょう ● Bugreport 実行時や ANR 発生した時の VM ス タックトレースを出力 ● 問題が発生していた時の実行メソッドを特定 できる
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
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)
問題箇所を探すには ? ● 赤丸の箇所がダンプ取得時のプロセスが実行 していたメソッド ● 想定される処理待ち以外で止まっているプロ セスがないかをチェック
例外でリブート ● logcat で例外発生時のスタックトレースを確 認 ● Java の場合は素直にスタックトレースを見れ ば大体分かります ● Native の場合は ...
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
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: ● ...
発生箇所を特定する ● #00 pc 00010a20 /system/lib/libc.so の箇所から、 libc.so の 0x00010a20 にて signal 11 (SIGSEGV), fault addr deadbaad が発生していることが分かります
発生箇所を特定する ● addr2line でどの関数で発���しているかを チェック ● JellyBean の場合、 – prebuilts/gcc/linux-x86/arm/arm-eabi- 4.6/bin/arm-eabi-addr2line
発生箇所を特定する ● arm-eabi-addr2line -f -e (path to libc.so) 0x00010a20 ● これで発生関数が特定できます ● out/target/product/(Board name)/symbols 以 下のデバッグシンボル付きライブラリを指 定すれば発生行まで特定できます ● 後はスタックを上にたどれば作成した箇所の どこで問題が発生しているか特定できます
まとめ ● ログが取れれば以上の方法で原因追跡できま す ● 大体リブートバグの 9 割くらいはこれで追え るかな ● 一番難しいのはバグを再現してログを取るこ とです 以上

More Related Content

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 割くらいはこれで追え るかな ● 一番難しいのはバグを再現してログを取るこ とです 以上