Orz日記 by Akio Morita

_ [LHC]5TeV衝突の方向で

クエンチを避けるため7TeVではなく、5TeV衝突で立ち上げるようですが、 最近LCU(LHC Commissioning & Upgrade)ミーティングでも 5TeV時の アパーチャや光学系パラメータを検討した話が話題になっています。

_ [SAD]alsad3で FileDialog[]が

暴走するというバグレポート＆調べろ指令が来てたんで、 KEK内のホストに Xvnc Server環境を構築してそこ経由で 調査を3時間ぐらい実施。

報告内容は、「特定ホストalsad3(系列機が存在しないので 特定アーキテクチャとも言える)で特定のSADパネル (X Clientなので、そのまま CERNへ連れてくると画面開くだけで 10分以上かかる)で、KBFOpenDialog[]するとスタックする」 と言うものだったのですが、聞いたこともない＆発生率100%という かなり変な症状です。(確率的な障害なら、レースコンディションを 含んだ実装等に思い当たる節が無いわけでは無いのですが...)

• (報告によれば)他のパネルや小さなコード上でのKBFOpenDialog[]は問題無し
• (調査＆検証により)PIDが連番のプロセスを大量に fork(2)した状態でスタックする

あからさまに変です。なんで大量に fork(2)してるんだよ...Orz

まず、fork(2)システムコールがおかしかったら OSがまともに 動くはずも無いので、この可能性は除外というか、SADの責任じゃないよ！

KBFOpenDialog[]内で連続してFork[]が呼び出されるのは、 コードフロー的にあり得ないというか、そういう事態が起きるとすれば、 インタープリターは既に正常に動作していない状況なわけで... 明らかに実行モジュールsad1.exeが、 内部で問題(多分メモリ系)を起こしているか、腐っているかという線が濃厚。

で、他人の作った実行モジュールにプローブ差し込んで調べるのは 面倒なので、当該環境でクリーンビルドな実行モジュールを生成して 検証してみたのですが...障害が再現しないよ Orz

いつものように amorita branchで検証してたんで、CVS MAIN trunk固有の 障害を疑って CVS HEADでも検証してみるも、再現せず。なにゆぇ...

問題の実行モジュールのVersion Stringから その当時のソースツリー構成を 推定(前後数日の誤差有り)して構築してみるも、再現せず。

この実行モジュールって、どうやって作ったんだ！

Sticky Tagで意図的にソースを固定せずに、cvs checkoutしたままの ソースツリーで作られたとすれば、再現したソースツリーの構成は かなり近いはず(関与するコンポーネントという意味で)なので、 コンパイル環境かコンパイル設定の不良とかストレージの不良とかが 怪しそうなんですけど... Orz

なんか、3時間ぐらい検証作業やってたけど虚しすぎ...

バグ報告の前に、環境をクリーンビルドして障害が再現するか 試験して欲しかった

_ [LHC]β*ノブ自動化

Brute Forceな方法で自動マッチングを実装。 一応動いているが、激しく遅い Orz

_ [SAD]バグレポート

先日の積み残し案件を報告したが、 tturn1 @ src/tturn.fの SOL要素は 実装方法自体を修正すべきだとのコメントが来ている。

誰が、再実装するんだ Orz