「どのように戦っていたか？」といえばケースバイケースとしかいいようがないですが。
３日ほぼ徹夜状態で悩まされたのが私の史上最大の再現性の低いバグでしたかね。
原因を先に書いておけば。
ハード回路のRTC（リアルタイムクロック）の線とファイル操作する（SDかCFか忘れたけど）データ線が近くで並走していたかなんかでデータが時々コケる。（ファイルの書き込みでデータがばける）という問題が発生していました。これが１時間に１回RTCが出す信号と、ファイルの書き込みが競合した時のみ再現していたので再現頻度はかなり低かったのです。
これをオシロ無しで顧客とアプリ屋と私（ファーム屋）だけで解決しようと試みた時の戦いが一番厳しかったなぁ。
ハードをブラックボックスと考えた場合、RTCとファイルなんてまったく因果関係の無いものですしね。
これをどうやって解決したのかって、ひとつずつ仮説を立てて検証し。を繰り返しただけです。
ハードの回路は多少読める程度ではありますが、これだとマズイとかいった話はわかりませんし、見るとしても論理回路までです。実装基板の回路なんて見ませんしねｗ
二日目くらいにお客様のリーダが言ってました。
くりもとさんの仮説はそれぞれ納得ができる。そうだと思った。しかしここまで全てそれが外れている（期待したように動かない）。いったいなぜなんだ？と、会議室にずらーーーっと何十本のコーヒーカンが並べられてる中で悩み続けていたお客様をいまだに忘れられないｗ
三日目にRTCを殺したら再現しない事に気がつき、さらに００分の時に再現する事に気がつき、59分58秒から00分01秒までファイル書き込み禁止すると再現しなくなった時の皆のチカラの無い喜びようときたらｗ
（原因がわかればRTC設定を何回も設定しなおし再現性を上げる事ができる）
という感じで再現性を上げる戦いでしょうかねぇ。それはつまり原因の追求という意味ですけど。
とはいえ、今の時代。ひ弱なハードを使う割合は下がっています。
結果としてどうするのか？というと、そもそもですが再現性の低いバグがでやすい作り方は推奨されなくなっています。
中身では激っぱやな速度で処理されていきますから処理をシリアライズして競合問題がそもそも発生しないように順番にいっこずつやっていっても処理が間に合うように作るし、ハードも用意されがちです。
まぁ予算が少ないプロジェクトだとチープなチップを使う場合もありますが。そういう時に大それた事をしようとは思わないプロジェクトが多いですから？ｗ（語弊？ｗ
再現性が低いというのは大抵の場合タイミング系の問題です。これは昔であればしょうがない領域がありますが今時だとハードスペックが顧客の要求スペックを凌駕しているのでソフト的に少々無駄遣いしても事足ります。
それならリスクが高い作り方をして高速化するより多少無駄でも安定的に動作する（競合箇所を最小限に抑える）作りにすればバグはあってもタイミング系のバグは激減します。（再現するなら100%再現する的なバグしかない）
そしていざ発生すると、いかにして再現性を高めるか？を血眼になって探します。としか。
でもまぁ、一部では要求水準が高いプロジェクトもあり（特に映像系）
1μ秒の世界の集積データを処理するって・・結構泣けます。
Windowsって知ってます？10msecのディスパッチですよ？
10000μ秒単位って事ですよ？というのをVGAですら640x480のドット数があり。やーれやれ。な世界ではありますが。
こういうのを作ってる時はタイミング系な話がチラホラでてきます。
というわけで「どのように戦うのか？」と問われれば。
泣きながら戦ってます。
ですかね？ｗ
0 コメント:
コメントを投稿