Android デバッグ小ネタ
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Android デバッグ小ネタ

on

  • 8,003 views

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

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

Statistics

Views

Total Views
8,003
Views on SlideShare
7,999
Embed Views
4

Actions

Likes
4
Downloads
28
Comments
0

3 Embeds 4

https://twitter.com 2
http://s.deeeki.com 1
https://www.chatwork.com 1

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Android デバッグ小ネタ Presentation Transcript

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