Android デバッグ小ネタ

14,138 views

Published on

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

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
14,138
On SlideShare
0
From Embeds
0
Number of Embeds
2,679
Actions
Shares
0
Downloads
32
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide

Android デバッグ小ネタ

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

×