備忘ぶ録

プログラムの処理をたどるのに有効な手段として、ログ出力がある。
ログを取る目的は、「問題が発生した時＝意図しない動作をしたときに、なぜその動作になったか解析できる情報を自動的に常時取得する」ことである。

究極的には、問題が発生した部分についてだけの情報（処理の流れ、処理しているデータの値＝変数値）が取れればよい。

しかし、どこにバグがあるかわかるわけがないので、ログを取得する箇所を局所化することはできない。バグが潜んでいるところが分かっているなら、さっさと直せば済むことだし。
となると、どこで問題が発生しても良いように、全体的にトレースログを埋め込む必要がある。
しかし、トレースログは、本来必要な処理ではないので、多量に埋め込むと性能劣化、リソースを多く使うという問題につながる。また、多く埋め込むとソースが見難くなるという問題も発生し、トレースログ自体がバグの原因となる可能性も高くなる。たとえばポインタのメンバ変数を見ようとしたら、NULLポインタだったので落ちたとか、数値を出力しようとしたのに出力子を”%s”としてしまいとんでもないアドレスを文字列として出力してしまい、アクセスバイオレーションになってしまったとか・・・。

処理の実行履歴＝トレースを追うのなら、デバッガでステップ実行するのも可能であるが、以下の問題がある。
① 処理全体を追うのは大変
② ユーザのところで問題が発生した時、発生した時点の処理履歴が欲しい。ユーザのところで問題が発生するまでデバッガで実行するわけにいかない。
デバッガのステップ実行を行ってのデバッグは、トレースログで問題個所の辺りをつけて、より詳細な動きを確認するために行う行為である。なので、トレースログに取って代わるものではなく、補完するために行うことなのだ。

では、トレースログで取得しなければならない情報は、何か・・・。
難しいので、また今度考える。