『Debug Hacks デバッグを極めるテクニック & ツール』感想

『Debug Hacks』を読みました。読みましたつっても、そもそも門外漢過ぎる分野の話が多いので、基礎知識のおさらい、アプリケーションデバッグ、その他ツールの使い方のあたりを読んだだけで、カーネルをデバッグして云々ってなところはほとんどとばしてしまいましたが……。しかしそれでも、得るところが大きかっただろうと思いますし、今後、色々と役に立つこともあるのではないかなあと、期待します。

Debug Hacks -デバッグを極めるテクニック&ツール

僕は普段はだいたいPerlでしかコードを書かないので、本書にあるような、GDBやら様々なツールを使い倒してデバッグしまくるみたいなことはほとんどありません。また、Perlにもデバッガはありますが、あまり使うことはなく、もっぱらいわゆるprintデバッグで済ませていたりします。しかしまあ、普通のWebアプリケーションの開発においては、わりとだいたいそんな感じなんじゃないかと思ったりします。最近ではローカルでフレームワーク付属のWebサーバを起動して、なにか変更があったら自動リロードしてくれるし、テストもちゃんと書きましょうねということになっているのですから、怪しいところをダンプしてまわったところで、そうそう手間がかかるわけでもありませんし、ほとんどのバグはそれで取れるでしょう。

しかし、そうやって書いたコードを、ステージング環境(本番とほぼ同様の環境)を経て、いざ本番環境で動かしてみましたといった時に、よくわからない問題が発生したりします。ローカルや開発環境では発生しなかった、あるいは認識されていなかった問題が、起きたりするわけです。社内のひとしか見ないような開発環境と本番環境とでは、もちろん実際には設定等細かいところで様々な違いがありますし、なによりもアクセス数の規模が全然違うわけです。また、なんだかメモリをばかばか食ったり、セグフォったりしてどうしようもないということになったりもします。そうなると、単純なprintデバッグではどうにもならなくなり、別の方法を用いる必要が出てきます。

というわけで、そういう時にどうすればいいか、「Perlプログラマのためのgdb入門(at Shibuya.pm #9 LT) - とあるはてな社員の日記」で述べられているような話を、社内勉強会等を通じて、学んでいるところだったりします。パフォーマンスを支える技術について知るのはもちろんのこと、たとえば、ロジック的に問題がなかったとしても、負荷がある点を超えるとどうにもならなくなるとか、条件のテストが例外的な場合に漏れて大変なことになったりするといった問題のあるコードを書くのを防ごう、また、そういったことが発生した場合の解決策を知ろうというようなお話しです。僕自身、そういったことにあまり通じてないものだから、日々お勉強なわけです。そのため、本書の、特にデバッグツールについての詳しい紹介は、とてもためになるものでした。

また、個人的に最近C/C++でコードを書くことに興味が出てきて、いろいろやってみているところなので、タイムリーでもありました。たとえばHack #13「アセンブリ言語の勉強法」などは「『Cプログラムの中身がわかる本』感想 - antipop」で感想を書いた本などを読んだばかりだったのだし、Hack #28「配列の不正アクセスによるメモリ内容の破壊」に「i386アーキテクチャのLinuxディストリビューションでは多くの場合、プログラムは0x08000000番地付近に、共有ライブラリは0xb0000000番地以降に配置されます(中略)デバッグ対象の環境では、標準的にどのアドレスにプログラムや共有ライブラリが配置されるかを覚えておくとバックトレースを見るときの参考になります」などという記述になるほどとうなずいたり(本書の全般的に、そのようなノウハウについての記述がとても多い)、Hack #63「GOT/PLTを経由した関数コールの仕組みを理解する」で説明されている、ライブラリ関数のアドレスを動的に決定する仕組みであるGOT/PLTなど初耳な話に、知るべきことの多さを思いしったのでした。

個人的には、読んだはしからすぐに役立つという話ではほとんどないものの、より深くコンピュータを知るためにはもっともっといろいろなことを知る必要があり、また、そのきっかけを与えてくれたという意味で、理解が困難ながらも目を通すことができてよかったかな、と思っています。