• - Facebook Page

  • - GOLE1

  • - Google+

  • - My Room

  • - 周辺風景1

  • - 周辺風景2

  • - Highway1

  • - Highway2

  • - Steam

  • - My site

  • - Profile

  • - 周辺風景3

´Д`)< 色々と思い出すなあ……

過去の日記でExcelに絵を描いていたやつ。あれをゴソゴソと対応している。
しかしやりたいことは絵に描いた通りなんだけど、それを JavaScriptで実現する方法がはっきりしていないから "3歩進んで2歩下がる" を繰り返している状態。書いては消してを繰り返しているからソースも汚い;´Д`)

ただまあゆっくりとだけれど、形にはなってきているような気がする。
……色々と不安な箇所はあるが;´Д`)

スレッドを使ったアプリのデバッグがよくわからん

先日の絵の通りなのだが、なんとなく JavaScript"専用スレッド" とかいうやつを使ている。しかしこれが厄介で……。
まず、Local環境の場合、スレッドを使っていると Google Chromeがセキュリティーエラーを吐く;´Д`) どないせえと
ちょっと対応が面倒っぽかったので Edgeを使って進めているが……Worker threadに break pointが貼れない ;゚Д゚)< ナゼダ・・・

いや、貼れるはずなんだ。ただ、貼るための操作方法が分かっていないだけで;´Д`)

そんな感じのえっちらおっちらな感じで進めているが……。

´Д`)< ログ出力を使おう

そうだ今までずっと仕事ではログでデバッグしてきたじゃないか。パソコンだからリッチなデバッグ環境を使わなければならないわけじゃないさ!よい子の味方、console.logさんに頼ってしまおう。

´Д`)< 過去を思い出してしまう

こうしてログを埋め込んでいると色々思い出すことがある。
組み込み系だったから……ってわけでもないと思うんだけど、ログは不具合が発生したときの最後の頼み綱になりかねないものだから、入れる場所、出力する情報にはホントに気を付けないといけない。

過去に何度か「将来のデバッグのためにログを入れておいて」と言われ、思うままにログを入れた結果、ほとんど解析の役に立たないようなログを入れてしまったことがある。もちろんめちゃくちゃ怒られた。怒られたが、結局どう対処するのが正解なのかは分からなかった。

最初にログを入れる場所

「どの場所で発生するか分からない」という不具合を捕まえるために入れるログ。
ソース1行ごとにログを埋め込むか?というとそんなはずはない。後々になってからようやくわかり始めたから、自分が知っていることを少し書いておこうと思う。
なんていうか、ログを入れる目的が不明確なのが問題なのかもしれない、と思ったり。

  • 不具合が発生したときに真っ先に聞かれる内容について答えるためのログ

問題が発生したときに聞かれること。それは「#゚Д゚)< どのチーム(どのモジュール)の問題じゃゴルァ」。
自分のモジュールが怪しい動作をしているなら、

  • 変なデータを渡されたからなのか
  • 他のタスクに邪魔されて動けていないからなのか
  • 出力データを渡したいけど輻輳制御で詰まってて……なのか
  • 外的要因は考えられないから、自分のモジュールのロジックに問題がありそうなのか

その切り分けを行うために、外部モジュールとの入出力部分にログを入れる。もちろん入力部分は入力してすぐの箇所。出力部分はデータの作成が完全に完了し、相手先へ渡す寸前の箇所。
ひとまずこれさえあれば問題発生モジュールの切り分けはできるはず。

次にログを入れる箇所

モジュール間通信 (http, ftp, Message, pipe, shared memoryなどなど) での切り分けができる情報が出力できたら、次はライブラリ使用部分かと思う。ライブラリと言っても開発言語の標準ライブラリではなくて、他チームから提供されている API 部分の呼び出し前後など。
とにかく問題発生箇所を絞り込んでいける情報が必要になってくる。最終的に自分のモジュール単独問題だと分かったならまずその内容を報告して、詳細解析に進むかもっと他の優先不具合解析になるかはその状況しだいという感じだろうか。

なんにしても "入力データが明確" になっていて、"自分のモジュール内ロジックが問題"だと分かったなら、その入力データを再現させてステップ実行すれば再現できる可能性はそれなりに高いはず。
もちろん "現象発生時はたまたま処理負荷が高くなっていて……" ということもあるだろうけれども、まずは 単純な問題をすぐに絞り込める ようにログを入れておくのが重要かなと。

その他:他チームのログも普段から見ておこう

他チームが不具合解析の助けになる情報をログに仕込んでいることがある。例えば「ログ出力日時」「CPU負荷状態」など。
また、処理負荷が高くなっているときのログ出力パターンを見ておくとか。例えば電波状態が悪い時のログなど。そういう状態ではたいていどこかのタスクがひたすら回り続け、ログを出し続けているはず。そのタスクが自分のタスクより priorityが高い場合に自分のタスクが動けなくなることはないか、動けない状態でMessage queueに要求が積み上げられて、取りこぼしたりすることがないか、など。

;´Д`)< ログと関係なくなってきた

なんだか内容がログと関係なくなってきたのでこの辺で話を切り上げることにする;´Д`) 年寄りの話は長くてすまないネェ……