名探偵コナン並みの推理力をもったプログラマーにデバッグとか手伝ってもらったらどうだろうか。

? Takayuki Okazaki (@watermint) December6, 2011

なんて思ってたら、

@watermint つまり、「毎週超難解なバグが発生する」ということですね？＞＜

? パレオはせとあずさ♂?熱烈歓迎DeNA／ (@setoazusa) December6, 2011

！！！
お客様の中に名探偵の方はいらっしゃいませんか？＞＜

ということで、iOS Advent Calendarのネタです。今回は、iOSデバッグ界隈の中ではマイナーと言われるか、一部のファンに熱狂的な支持！といわれるか絶妙なバランスを保ったDTraceでのデバッグを取り上げます。

DTraceはもともと、Sun Microsystemsによって開発されSolaris 10に搭載されたデバッグフレームワークです。現在は、FreeBSDやMac OS Xなどでも利用することが出来ます。詳しい説明は今回は省きますがTraceと名前がついていることから想像できる通り、プログラムの実行をトレースしてどのコードが、どういう風に実行されたか。といったことを調べることが出来ます。

こんなことはありませんか？

1. 初期化処理がどうやらうまくいっていないようだが、どこまで実行されたか知りたい。しかし、Xcodeのデバッガでステップ実行・ブレークポイント設定などしながら確認するにはプログラムが大きすぎる。
2. NSLogを埋め込んでどこまで実行されたか確認したいが、そもそもログを埋め込むのが面倒くさい。または、ソースコードをNSLogだらけにして汚したくない。

個人的にはXcodeのブレークポイント設定はなかなかよく出来ていると思っていて、多くのケースではそれで足りると思っています。

Xcodeでブレークポイントを設定してActionにSoundを設定、ブレークポイントは自動的に続行するように設定しておけばその該当箇所が実行されたかどうか音で聞き分けて調べることが出来ます。初期化関連の問題を探すときなんかは個人的にはよく利用しています。

さて、これでも十分なんですが設定したいブレークポイントが増えてくると音の種類も限定されますしどの音がどのブレークポイントだったかよくわからなくなります。Log Messageなどのアクションを設定してログ出力するのもいいのですが、網羅的にブレークポイント設定は面倒くさすぎます。

こういうときに威力を発揮するのがDTraceです。まずは手っ取り早くつかってみましょう。XcodeについているiOSのサンプルプロジェクトLazyTableImagesを題材にしています。Xcodeであなたのデバッグしたいプロジェクトを開いて、シミュレーター上で実行してください。出ましたか？

次にターミナルから次のコマンドを実行します。

$ ps ax | grep Simulator | grep -v iPhoneSimulator

すると次のようにiOSシミュレーター上で実行されているアプリのプロセスIDが分かります。下の例だと85894ですね。

85894   ??  SX     0:00.33 /Users/watermint/Library/Application Support/iPhone Simulator/4.0.2/Applications/993BF578-B81F-4B4C-97FA-B6B6843DD47E/LazyTable.app/LazyTable
88978 s004  R+     0:00.00 grep Simulator

さてこれが分かったら続いてdtraceを実行します。dtraceは他の人の実行しているプロセスなども丸裸にしてしまうなどでき、セキュリティー上の課題があるため一般ユーザでは実行できません。sudoをつかって実行しましょう。下記の85894の部分は調べたプロセスIDに読み替えてください。

$ sudo dtrace -p 85894 -n ‘objc$target:::entry { printf(“[%s %s]\n”, probemod, probefunc); }’

できましたか？できたらアプリを適当にタップするなど動かしてみてください。

このようにObjective Cで実行された関数がリアルタイムに出力されます。どうでしょうか？これでNSLogを仕込まなくてもトレースがとれるようになりましたね。でもちょっと出力が多すぎるようです。これではデバッグの役に立てるにはややしんどいです。出力を抑制してみましょう。

objc$target:::entryのところを、objc$target:クラス名::entryと書き換えてみましょう。ここではLazyTableImageにあるクラスのIconDownloaderとしましょうか。実際に実行するときにはあなたのプロジェクトにあるクラスをつかってください。

$ sudo dtrace -p 85894 -n ‘objc$IconDownloader::entry { printf(“[%s %s]\n”, probemod, probefunc); }’

出力が一気に減って、IconDownloaderだけになりましたね。ご想像の通り、関数名でもフィルタできます。

$ sudo dtrace -p 85894 -n ‘objc$target:IconDownloader:-indexPathInTableView:entry { printf(“[%s %s]\n”, probemod, probefunc); }’

便利ですね。これでたとえば、初期化処理のときに通らなければならない関数がちゃんと実行されているかどうか分かるようになりました。クラス名や関数名にはワイルドカードが使えます。たとえば、IconDownloader以外にIconButton、IconButtonLabelなどのクラスがあった場合にはIcon*というようにアスタリスクを指定するとIconで始まるクラス名にマッチします。

さて、デバッグしていて原因箇所がなんとなくわかってきたときに知りたいのはその関数がいつ、どこから呼ばれたか？です。呼び出し元を知りたいですよね。そういうときは、もうちょっと凝ったdtraceの使い方をしてみましょう。

次のようなファイルを用意して、trace.d というファイル名で保存しておきます

#pragma D option quiet

self int level;

objc$target:::entry
{
  printf("%*s[tid=%lld][%s %s]\n",
    self->level * 2, " ->",
    (long long)tid, probemod, probefunc);
  self->ts[probefunc] = timestamp;
  self->level++;
}

objc$target:::return
{
  time = timestamp - self->ts[probefunc];
  self->level--;
  printf("%*s[tid=%lld][%s %s] [%dms]\n",
    self->level * 2, " <-", (long long)tid,
    probemod, probefunc, time / 1000);
}

ではこれを実行してみましょう。

$ sudo dtrace -p 85894 -s trace.d

このように関数呼び出しをツリー状にしてダンプできます。後は必要に応じてクラス名や関数をフィルタしていけば良いでしょう。

さて、すこし駆け足になりましたがXcodeのデバッガをつかう場合と比べてだいぶ便利な機能があることがお分かりいただけたでしょうか？

コマンドラインからの実行に抵抗があるというかたはInstrumentsからもDtraceは実行できます。

さて、すこし駆け足になりましたが最後に制約事項を説明しておきます。dtraceはOS側に仕込まれたプローブという検出ポイントに対して働きます。このため、トレースしたい内容のプローブがOS側で実装されていることが必須です。このため、dtraceのプローブを持たないiOSにはdtraceを接続できません。必ずiOSシミュレータ上で実行しているアプリに対してdtraceを実行してください。

iPhoneやiPadなどのiOSが動作している実機に対しては別途従来通りのXcodeやgdbを用いたデバッグが必要です。

Mac OS XのdtraceにはObjective Cのためのプローブがいくつか用意されています。詳しくはman dtraceを参照してください。

言語環境を変更するにはシステム環境設定から、言語とテキストで順番を入れ替えるだけ。?さて、英語環境にしたときに困るのが、いくつかのアプリケーションは日本語環境でなければ正常に動作しないこと。Illustrator、Photoshop、Safariあたりがそう。Illustratorはプラグインの読み込みにいくつか失敗し、Photoshopは実用上困ったことはないけれど一部メニューが文字化け、SafariはAccept-Languageがenになって一部Webが文字化け。そういうときには、個別にアプリケーションに対して言語設定を実施。Mac OS X 10.5 LeopardまではFinder.appから設定できたけど、Snow Leopardではできない模様。

コマンドラインで次のように入力。

defaults write $(mdls -name kMDItemCFBundleIdentifier -raw /Applications/Adobe\ Illustrator\ CS4/Adobe\ Illustrator.app) AppleLanguage “(ja)”

のように入力してアプリケーションを再起動すれば完了。

少し前の話ですが、7月末頃、iOS 4.0からiOS 4.0.1にアップデートしようとしたところ、「iPhone”iPhone”を復元できませんでした。不明なエラーが発生しました(9)」というエラーがでてアップデートが完了しません。iMacを再起動してみたり、MacBook Pro側で試してみたり、違うUSBポートから実行してみたりなどかなり多くのパターンを試してみましたがどのパターンもだめ。

何度試してもiPhone 4側にiTunesにつないで復旧せよ、という表示のまま。仕方なく、渋谷のApple Storeへ持ち込み。Apple Storeでも現象が再現し、iPhone 4本体は交換となり無事復旧しました。

ちなみに交換してもらったため、本体への技適マーク表記がなくなっています。iOS 4は技適マーク表記があるので電波法上問題はありませんが、本体に印字されているという希少価値がなくなったのはちょっと残念。まあ、新しくなったのでよしとしましょう。

ブログに書くのが遅くなりましたが、iPhone 4が届きました(6月29日)。2年間つかったインターネットマシンことSoftBank 922SHからの機種変。なんだかんだ、届いてから1ヶ月ぐらいですね。

Retina Displayは確かにおそろしくきれい。デバイスの持つ表現力もさることながら、iOS自体もこれに向けて周到に準備が整えられていたのが大きいと思います。高ppi対応は記憶が正しければ、Mac OS X Leopardあたりから本格的に入り始めたので3年の月日をかけて熟成させ、MacではなくiPhoneに最初に導入された訳です。WindowsもVistaからは高ppi対応が入っていて、2007年当時、これからはディスプレイが「○?○万画素！」と謳われて電気屋で売られる想像を当時していましたが予想は外れて、2010年ようやくスマートフォンがその戦いを始めようとしているようです。

iPhone 4を約１ヶ月使っての感想です。iPhone 3GSも平行して使っていますが、使ってみるとiPhone 4は確かに優れていますがiPhone 3GSを置き換えるほどではないことに気づきました。なぜなら同じアプリがiTunesによって同期され、Mobile Meによってメールや連絡先などの情報は同期されているので使い勝手は何ら変わらないからです。言い換えれば、iPhoneの魅力はやはりアプリであって、iPhoneというデバイス自体の機能や性能差というのは微々たるものだと感じるようになりました。

日曜日から実行しているTimeMachineによるバックアップがそろそろ終わりそうです。バックアップが10%ぐらい終了したあたりから、急に7MBytes/秒程度のスループットが出るようになりました。

何かのタイミングで、プログレスのダイアログが出なくなってメニューバー上にしか出なくなりました。あと残り約40GB。この分だと明日の朝には終わってそうです。

まだ実行中です。うちのTimeMachineバックアップがおわるのがはやいか、iPhone 4が出るのが早いか。まだまだかかりそうです。いったいいつ終わるんだろう。

上図はほぼ同時刻に開始したコピー処理ですが、Time Machineのトランザクションはおおよそ1/15の速度です。もし処理時間が単純コピーの処理に比例するなら、あと25〜30日といったところでしょうか。こんな悠長なバックアップで間に合うのか・・・・。

• Topic : Unable to export Slideshow in A3

試行錯誤の結果、42分のスライドショーを20分程度ずつに分けて、エクスポートの形式をH.264ではなく、MPEG4、720×405@30fpsで出力ができました。DVD出力用に854×480@30fpsも試しましたが同じエラーで失敗。どうやら、何らかのサイズに影響されてエラーが出ているようです。

Software Updateが出ていたので、なおるか期待しましたが、やはり同じエラーで失敗。仕方なく、720×405@30fpsのムービーでDVDを作ることにしました。

あとはDVD Studio Proで仕上げ。