grep地獄。
ログのサンプル：
DEBUG:Task0:Info Enter FuncA
DEBUG:Task1:Error failed to open 'hoge.cnf'
DEBUG:Task0:Info Leave FuncA
で、Errorのログを出している場所を探す場合、固定でない文字列の扱いが厄介ですね。
正規表現を使えばなんということもないと思うのですが、固定文字列の部分だけを検索して眼で絞り込んだ方が速かったりします。
このログを出しているコードは、たぶんこんな感じです。
ログ出力コードのサンプル：
if ( result==C_OK ){
// 成功した場合
}else{
// 失敗した場合
DEBUG_PRINT ( "Error failed to open '%s'\n", file_name );
// 中身はvsprintfとか
}
「DEBUG:Task1:」の部分は勝手に付加されるパターンですな。
で、以前試したことがある取り組みとして、このログ出力コードから、ログ解析用のフィルタを書くという無駄のための無駄のようなものがあります。その際に検討したことを少し書いておきます。
- printfの書式指定子から、正規表現のパターンを生成する
たとえば%ldなら数字のはずで、対応する正規表現では[0-9]となります。複数桁でも[0-9]*としておけば、連続する数字に勝手にマッチしてくれます。
- 全ソースを舐めて、全てのデバッグログ出力コードの書式指定を洗いだす
この処理自体は前提条件を満たせば、正規表現のパターンマッチで比較的簡単に実装することができます。
ログ出力コードが複数行にまたがっているとやや面倒そうです。バイナリからstringsコマンドで文字列定数を抽出した方が早いかもしれません。
stringsコマンドで文字列定数を抽出したサンプル（先日のエスケープシーケンスのサンプル）：
yasuda@R3 ~/src
$ strings esc.exe
%x@@
C@@0@
$@ @
This is
[34mblue
[0m
This is
[1;34mlight blue
[0m
__main
_impure_ptr
calloc
cygwin_internal
dll_crt0__FP11per_process
free
malloc
printf
realloc
・・・なんだか関係のないのがいっぱいありますねぇ。
- 得た正規表現のパターンを用いてログを解析する
短いパターンが先にヒットしてしまうのを避けるなどいろいろ面倒も多そうですがなんとかなるでしょう。
ソースを舐めるときに、ログ検索パターンとソースのヒモ付けができれば、ちょとしたログブラウズ用のHTMLを吐き出すことも可能でしょう。リンクを埋め込んで、ログをクリックしたらソースへジャンプするような。
もちろん警告やエラーは色を変えたり、タスクごとに字下げしたりと、可読性を向上するアイではいくらでも沸いてくるかと思います。
- ログ出力コードにフィードバックをかける
同じ文言や、複数行に渡るもの、あるいは短すぎるログは解析の妨げとなります。徐々に洗練させるための情報を提供することができます。
また、ログの内容自体を吟味する機会にもなるでしょう。
＊＊＊
ここまでデバッグログの解析に手間をかけなければならない場面は少ない気もします。
ですがまぁ、ビルド～実機でログ採取というような、トライ＆エラーを繰り返して時間を潰すよりは建設的なアプローチかもしれないと考えています。
コメント