一歩前進

何やってるんだろう、なんて思いながら、やっと治具が動いた。(ってか、一年半前に作り上げたエミュレータを、新しい環境で動かし直しただけ。)某社の某マシンのエミュレータ。仕様書なしで通信データだけを読んで、マシンの動作を完コピした。
復活!でも、バテバテ。

仕様書や文書が調っていないプログラムのメンテナンス、通信プロトコルをプログラムから読まなきゃならないような通信ソフトのメンテナンス、設計者が会社を辞めてしまって、どうにも修正できないプログラムの延命パッチ、などは得意といえば得意ですが・・・窓口会社を通していただく、ということで・・・(直接お金の話はしたくないので)。

良かったぁ、って違うでしょ?これからやっと仕事が始まるってのに、もうこの時間。

「製品」の動作確認するための「治具」が、こんなんでいいの?(トラップの作りが雑)、とは思うが、プロトコル上は完全に某社の某システムと同じ動作する。
よくある話で、フィッシングサイトなんかと同じ。

例えていえば、可愛い女の子とチャットしているつもりが、実は無精髭生やしたオッサンだった、なんて感じでしょうか。
「今度会いたいなぁ。でも上京するのにお金がないからぁ、・・・」なんて言われてつい、鼻の下をのばして・・・

論理のトレース

バグを潰しにかかって、一番厄介なのは表面的に起きている現象と原因との乖離、なんだろうな。
一つ前のページ、原因は自作関数の戻り値の検証不足。接続できることを試したかったから、つい先を急いだ。エラー処理系は手抜き。その結果エラー・リターンと、正常動作のカウント0の戻り値が同じになってしまい、原因を見つけるのが遅れた。
開いたファイルは必ず閉じる。(COBOL系の人はこれをやらない。言語処理系が自動的に閉じてくれるから、閉じない習慣があるらしい。自動ドアに慣れていると、自分でドアを閉じないのと同じか。)C++なのに、閉じていなかった。これも、先を急いでいたから。ここで、やっちまった。なおかつ、自分の意識の中でWrapperの戻り値をシステムの戻り値だと勝手に決め付けてしまっていた。

丁寧に、ステップごとに辿れば、この類のバグは必ず潰せるんだけれども、思い込みで注目点がズレていると、原因部分へのアプローチが遅れる。ものすごく時間がかかった。

基本的に、私はモノグサだから、面倒なことはやりたくない。そうすると、一番厄介なところ、自分で「完成品」と思っている箇所を無意識に避けて、勝手に論理をすり替えて、「この現象の原因は、ここにあるはずだ」と思い込んでしまう。こうなると、ドツボ。まさかとは思ったけれども、ps(プロセス状態取得)が誤動作していると、勝手に決めつけて、そこばかりを調べようとしていた。分かる訳がない。これで数時間ロスした。

一番怖いのは、論理のすり替え。すぐに論理をすり替える人に論理的な説明をしても、全く意味がない。だって、すり替えた先にはなんの問題もないんだもの。それと全く同じ。

相手がコンピュータで良かったと、つくづく思う。相手が人で、こちらは論理的に説明しているつもりが、寄り切られると、最後は自分自身を捻じ曲げるしかなくなる。
まず拒絶、次に思い込みと決め付け、そしてマウンティング。
それが続くと、自分の側が原型を留めなくなる。

どこぞの国との交渉も、「交渉」はできても「議論」にはならないだろうなぁ。ニュースを聞いていて、体から力が抜けた。こちらの主張を理解してもらう、なんて無理じゃないかなぁ。だって、全く聞く耳を持たずに一方的な主張しかして来ていないと思う。

そもそも、戦略管理物資が不正に流れていることの指摘は、アメリカ側から来たんじゃないのかなぁ。そのアメリカに、某国がどういう説明をしたのか、とても興味がある。きちんとアメリカが把握していた事実に合致する説明を、したんだろうか、それとも、何か都合のいい「作文」で説明したんだろうか。一度作文しちゃうとそれが一人歩きするから、もはや「事実」など霞んでしまう。あれは作文でした、なんていう撤回は、これまで一度もないと思う。その作文に基づい国民が大騒ぎする。直近ではレーダー照射がいい例で。
覆水盆に返らず。関係改善なんて、もう無理じゃない?

コンピュータ相手の仕事で良かったと、つくづく思う。純粋なロジック以外のことは、一切合切考えないようにしようとは思うんだけれども、脳ミソは一つしかないから、難しいです。

気を取り直して・・・

ps と grepでツボった話 <-- 初心者並 orz

反省箇所多し:自分への戒めで、晒しておこう。

発端は、なんか知らんけど、nohupとrbenvの相性が悪い、かな、と思った。最初はきちんと動いているのに、十数分後から

sh: 1: 1: Too many open files
nohup: 出力を ‘nohup.out’ に追記します

このメッセージが画面に溢れる。nohup.outを見ると

rbenv: cannot find readlink – are you missing GNU coreutils?
/usr/local/bin/rbenv/libexec/rbenv: line 22: /dev/null: Too many open files
/usr/local/bin/rbenv/libexec/rbenv: cannot make pipe for command substitution: Too many open files

この繰り返し。1秒間に10回はシェルを起動、実質的なマシンフリーズ。わからん。ツボった。

元を辿ったら、理由がわからないけれども、

ps -ef | grep puma | sed ‘/grep/d’ | grep -c puma

でpumaの起動を確認。別窓でrailsサーバは起動済み。それなのに、プロセス数が0で返ってきて、サーバが落ちてると勘違いして、nohupの起動コマンドが起き出す、で、同じポートを指定するから、多重起動をブロックされ、その後プロセス起動の無限リトライが始まる、とここまでは追い詰めた。

pumaは間違いなく動いている。クライアント窓からアクセス可能。grep puma自身のプロセスをブロックするために、sed ‘/grep/d’でその行を削除。正常動作では1が返ってくるのに、突然0が返り出す、この原因がわからない・・・psが走ってるプロセスを拾ってくれない、みたい。

半日潰した。やり方変えようかなぁ。何が起きているんだろうか。プロセスのrun状態を見るのに、何かキャッシュが入ってる?kernel読まないとダメ?

ってか、これ、ダミーホストで完全な治具だから「私には解決できません!」と諦めるのがも正解かも。

こういうの、悔しいんだよなぁ。負けるが勝ちか?
問題を解決できないこと自体が悔しい。

意味もなく、自転車でぶらつくことにする。


いた。虫がいた。
if(++ret == count){
pclose(fp);
return ret;
}

としないと、パイプを開きっぱなしになるのに、

if(++ret == count) return ret;

なんて書いていた。初心者みたいなバグ。

cannot make pipe のメッセージを見落としていました。

バグに煮詰まったら、そばにいるプログラマを捕まえて、状況説明すると、だいたい自分で気づくってのがよくある話で・・・。私の場合にはそれがネットだった、ってことね。

反省箇所は、まだある。一年半前に書いた治具用のコード。自分専用だから、ちょっとテストランしてそのまま使っていた。よくよく読んでみると、popenのエラーを返すのに0を使っていて、カウント数0はサーバダウンの時に戻る「処理正常」の値。これが被っていた。ど素人か、みたいなミス。
賄い飯みたいなものだけれど、だからって適当に書いていると、こういうことになる。粗忽だ。
orz