2019年5月アーカイブ

Amazonアフィリンク

デバッグに主眼をおいて書かれた「Effective ...」なタイトルをかりた本。デバッグの方針から実際の作業まで幅広い内容を一貫して扱い項目にまとめ上げた内容になっている。LinuxシステムとJavaを対象にした内容が多いかもしれない。

デバッグを行う上での戦略(とっかかり方)に注意しながら項目立てしている点が好感触。いくつか出てくる具体的なツールについても、日本語版発行が2017年5月で、比較的最近のデバッグ状況を反映した内容になっていて、安心して読める。デバッグの内容についても、かなり実践的で踏み込んだ内容に仕上がっていて、ただでさえデバッグに的を絞った本が少ない中で、非常に貴重な本だと言える。

難しい内容も多いんだけど、比較的幅広い人に読んでほしいと思える内容になっている。中級者以上の人に向けて非常におすすめできる本。

以下、個人的な読書メモ。

P4「項目2: 問題に対する洞察を得るにはウェブで焦点を絞って検索する」より、マニュアル読むのもいいけど、ウェブ検索したりStackOverflow使ったりしろ、と書かれていて、なんとも今どきなアドバイスだなぁと思った。

P11「項目5: 既知の正常なシステムと問題を起こしているシステムとの違いを検出する」の後半より、なんだかんだでログファイルをdiff, cut, wak, grep sed, commコマンド類を駆使してゴニョゴニョしろ、と書かれていて、結局どこでも似たようなことをやってるんだなぁと。逆に言えば、そういテキストファイルの操作に遊び慣れておくことが重要なのかもしれない。

P20「項目8: 作業の焦点を最も重要な問題に絞る」より、バグの対応優先度を具体的な例で列挙しているけど、ホントこれ大事だなぁと感じる。モノによっては、しれっと直しておけば良いものから、直すだけでなく影響度・頻度・回避法、一度起こったら二度と復帰できない場合への対応方法の決定、とかとか。

P24 項目9より「デバッグは複雑なので、気を散らさずに専念する必要がある」、理想ではあるけどなかなかそうは言ってられん事が多いなぁという個人的感想が。案件によってはメールに分速の返信が求められることもあり、いろいろ辛いことが多い・・・

P30 「項目12: 複雑なテストシナリオを自動化する」より、複雑とはいえテストのためだけにLuaを移植するほど工数取れることなんてあるのかなぁ。できたとしてシェルスクリプトで複数回実行を自動化する程度なのが実情・・・

P15 項目15より「法律面でコードを変更しても問題ないことも確認する」、サードパーティのコードがあるだけましで、場合によってはバイナリしか提供してもらえず、しかもシンボルも削られててstraceくらいしか何もできなかったり・・・なこともあり、立場が弱いと開発も苦労しますよね。

P16 項目16より「プロトコルアナライザやバスアナライザのような特殊装置」、組み込みやってるとSoCやICの挙動が読めずにこの手のアナライザに頼らざるを得ないことも多くて辛い。他方で全部ソフトに閉じた場合だともっと開発のスピード感が求められるんだろうなぁ。

P20 項目21より「このような欠陥が将来はいらないようにするための処理を行う」、これ本当に大事で、せっかく直したのに少ししてからまた同じ過ちをやらかして・・・な例が本当に多い。チェックをソフトで自動的に行えるのならば、それもあわせてやっておいたほうが絶対に良い。

P65 項目26より「Gitを使って(中略)バグが発生した変更を特定することまでできる」、git bisectってテスト手順をスクリプトに書き出すことができればbisectの実行を自動化することまでできるようになってたのね。これ以外にも、gitを使ってバージョン間の比較やらcommitの入った時期・ブランチの調査やら、どこでも似たようなことをやってるんだなぁと感じた。

P94 項目36より「gdbコマンドで実装するのは、デバッグ機能をプログラムのソースコードに追加できない強い理由がある場合だけに限られる」、こと組み込みに限れはちょっとここはどうかなぁっと。不必要なデバッグコードを入れたままにすることが許されたり、RAM/ストレージの観点で余裕がどれだけあるのかだったりは気になる。これまでは非常に限られている経験が多かっただけに、逆に、gdbマクロでいかにデバッグしやすくするかを主眼においてきたけど、これからのarm-linuxなシステムだと富豪的デバッグのほうが主流になってくるのかなぁ。

P106 項目41より「ロギング分を使うのは、デバッガの使い方を知らない人間だけだと思いこんでいる人もいる」、使い物になるロギングが許されるほど最近のシステムは富豪的デバッグが許されるのかなぁ。別の観点だと、デバッガはあくまで開発ができる人向けで、ロギングはプログラムがわかってない人でもある程度は挙動の分析ができるとか。

P138 「項目52: ビルドと実行を決定的に構成する」より、再現性あるデバッグをするためにASLRやらseedの非ランダム化やらを語っていて、見過ごされやすい点だなぁと本当に思う。紹介されているサイトに少し興味を持った。https://reproducible-builds.org/

P139 「項目53: デバッグライブラリを使用してチェックするよう構成する」より、malloc()系デバッグで泣くことが多いので、紹介されてる具体的な手法が気になっただけでなく、この手の動的デバッグをすぐに切り替えて使えるよう事前に構成を準備しておくのも大事だなぁと思った。環境変数MALLOC_CHECK_を常用するレベルですら現場では意外とできてなかったりするし。

P176 「項目61: キャプチャして複製する」より、x86系だと実行内容を再現できるPinPlay/DrDebugなんてツールのがあるのね、ずるい。マルチスレッドデバッグもいろいろとツールが出てきているというのは新鮮に感じた。

P194 項目65より「プログラムをperfの下で実行し、関係するイベントを記録する」、他にもしれっとstraceが出てきているけど、今やperfやstraceは使っていて当たり前のレベルになってるんだと実感させられる。うん、確かにarmでもperfでパフォーマンスカウンタまで取れちゃうしね。やはり今後を考えるに富豪的デバッグのあり方を根本から見直さないといけないのだろうか。

Linux memo 2019/05/23

● zlibオリジナルの改良
Mark Adlerにzlibマージしろとつついている人がいる、さすがに無理筋では。
https://github.com/madler/zlib/issues/346
※ zlibは、zlib-ngはじめフォークしたプロジェクトでSIMD/NEON対応した最適化が進んでいるが、オリジナルzlibは個人プロジェクトに近い状態のため、成果をオリジナルzlibにcontributeするのが難しい状態が続いている。

● /dev/log
Linux...というかglibcでは、syslog(3)は/dev/logのsocketとして実装されている。socketなのでsyslogd側が詰まった場合syslog()を呼ぶクライアント側がブロックする。
http://tnetio.osdn.jp/cgi-bin/WalWiki2/wiki.cgi?99syslog
でも、今どきはsyslogdではなくてsystemdなので、systemd-journaldだったりするわけで、わけわからん。
https://harre-orz.github.io/journaldwojing-you-sezunirsyslogkaradevlogwoshi-u.html

このアーカイブについて

このページには、2019年5月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2019年3月です。

次のアーカイブは2019年7月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

月別 アーカイブ

ウェブページ

Powered by Movable Type 7.9.0