スラドに聞け:あなたがオススメするアプリケーション・パラノイアテストは? 62
ストーリー by hylom
そんなものがあったのか 部門より
そんなものがあったのか 部門より
m_nukazawa 曰く、
C++コンパイラの元祖とされている「Cfront」がリリースされてから30年が過ぎたことを記念して、Cfrontのソースコードをコード静的解析ツールであるPVS-Studioで解析したという話が公開されている(本の虫)。
この記事自体も大変興味深いのだが、タレコミ主が特に惹かれたのが、「パラノイアテスト」だ。引用されていたツイートによると、Google Chromeには通常ではありえないビット異常をチェックしてアプリケーションのバグと区別するために「パラノイアテスト」が搭載されているらしい。
タレコミ主は不勉強故か、パラノイアテストの確立された標準的な手法について書かれた書籍や文献に心当たりがない。また、Chrome以外で参考になるオープンソースプロジェクトを探すのも骨が折れそうだ。
そこで聞きたいのだが、スラドの諸兄は自分の関わったプロジェクトで、パラノイアテストを見かけたり、実装したことがおありだろうか。
心当たりや実際の知見、あるいは又聞きで聞いた根も葉もない噂などでも構わない。パラノイアテストについて思うがままに語り合って頂ければ幸いである。
大事なことなので二度書きました (スコア:2, おもしろおかしい)
目的は違うけど (スコア:2)
コード部分のハッシュを適宜算出して、変化が有れば殺すっていうのは、ある種の方面ではよくあること。
そのアプリケーションが (スコア:1)
幸福であるかを調べればいいのか?
Re: (スコア:0)
幸福に決まってるじゃないですか。幸福は義務ですよ、市民。
Re: (スコア:0)
露出狂のサンタが出てきたりするのかも
#あろ先生もなんか4コマの人になっちゃったなぁ…
Re: (スコア:0)
あれはぱらのい屋じゃないですか。
Re: (スコア:0)
雲界の旅人の続き描かないかなあ
普通にやりませんか? (スコア:1)
制御機器のプログラムだと、物理メモリアクセスに対して常時パリティチェックをかけるような専用タスクが走らせるのは
ごく普通にありますよ。
あと、たとえば
if a==1 {
// aが1のとき
func_1();
} else if a!=1 {
// aが1以外のとき
func_2();
} else {
// 正常ならここは通らないはず
kick_NMI();
}
などというコーディングはフェイルセーフプログラミングでは常識と思っているのですが、
このくらいなら普通のプログラマでも普通にやるのでは?
#もちろん実際にはオプティマイズでコード削除されないようにしますが
このコードの意図が理解できない (スコア:2, 興味深い)
if で弾かれた直後 else if を評価する間の一瞬のタイミングで
a が化けたのを検出するということなのでしょうか?
それが問題になるような確率で発生するのであれば
この if 文全体の前後でかなり高確率で化けてるでしょうし、
それよりもはるかに大きな確率でロジック自体のバイナリがダメージを受けてる気がするのですが?
例えば a == 1 の 1 や a != 1 の 1 が化けてたり、je が jne に化けてたり
仮に a の値化けを検出するにしても
a = b = 0;
のように値を別の変数にも複製しておいて
if (a && a == b) { ... }
else if (!a && a == b { ... }
else { エラー }
とした方が実用的なのでは?
uxi
Re:このコードの意図が理解できない (スコア:1)
タレコミのツイート [twitter.com]
「宇宙線が降ってきてメモリのビットが狂う」「ハードウェアのバグでメモリのビットが狂う」というのは非常にまれな現象だけど、Chromeくらいのユーザ数規模になるとけっこう日常的に起きます。なのでChromeで走ってるGCには、それらのビット異常を検知する機構をわざわざ入れてます。
実際の仕組みは知りませんが、プログラマが意識しなくてもGCがやってくれるところがポイントなんですかね。
Re: (スコア:0)
ノードの管理情報に冗長性持たせてGCでチェックしてるとかその程度の話じゃない?
Re:このコードの意図が理解できない (スコア:1)
サンプルコードが(擬似コードで)言いたい事のわりにはしょってるのでコメントが伸びているような。
想像するに、RAMは化ける可能性があるけどROMやCPUはハード的に保護して信頼性高くしてあって、というようなシステムのようだけど、RAMから呼んだ値はレジスタに置いて if 文を通るようにコーディングするんではないかな。普通ならやれることもできない、あれこれ制約されたコーディング規約もついて。
もしCPU/ROMもずっこけるというのなら、同一構成のシステム複数で多数決するとかなんとかしてやるだろうからif文でどうこうという話にはならないだろうし。
Re: (スコア:0)
・信頼できないデータを読んですぐ分岐するというのが理解できない
・もしa==1とa!=1でaを二回読んで欲しいというのなら、オプティマイズがどうのというのが理解できない
Re: (スコア:0)
クセにしといた方がいいですね。
ステートマシンの未定義ステートで元に戻すorリセット掛ける
# ムーアマシン ミーリマシン? 昔のことは忘れた
Re: (スコア:0)
条件式がa==1とa!=1ならそんなことしませんよ
a!=1と書くこと自体がバグの元
switch文の場合、行くはずのないdefaultに行くバグはあるから、それとごっちゃになってませんか
Re:普通にやりませんか? (スコア:1)
どうしてもこう書きたいならaはvolatileにしないといけないはずですが
Re: (スコア:0)
> #もちろん実際にはオプティマイズでコード削除されないようにしますが
Re: (スコア:0)
オプティマイズの問題だと思っているところが、問題なんです
Re: (スコア:0)
何を言いたいのかわかりませんが、
aがvolatileだろうが、volatileでなかろうがそういう問題ではなく、
a==1とa!=1が同時に成立する場合があり得るので、
そういう場合には、
> // 正常ならここは通らないはず
> kick_NMI();
を実行させる。
そんな事情わからないコンパイラが、勝手にオプティマイズで消す可能性があるので、
>#もちろん実際にはオプティマイズでコード削除されないようにしますが
ってことでしょ。
>条件式がa==1とa!=1ならそんなことしませんよ
>a!=1と書くこと自体がバグの元
とか、
>どうしてもこう書きたいならaはvolatileにしないといけないはずですが
とか、論外。
ビットが安定していることが前提の世界の話ではない。
Re: (スコア:0)
> a==1とa!=1が同時に成立する場合があり得る
同時はおかしいだろ。
Re: (スコア:0)
ソースレベルだとそうだけど、バイナリレベルだとどちらかの「1」のビットが乱れればあり得る。
Re: (スコア:0)
cmp a, #1
beq label1
bne label2
仮に上のような例で両方の条件分岐が成立するとしても、同時に判定しないので先に判定したほうが優先されるだけ。
Re: (スコア:0)
> aがvolatileだろうが、volatileでなかろうがそういう問題ではなく、
> a==1とa!=1が同時に成立する場合があり得るので、
RAMが化けるという話であれば、RAMをそのつど読むか一度読んだ値を使いまわすかは重要な話では?
Re: (スコア:0)
IC内のロジック設計でも同様です。
信頼性を確保する必要がある用途では、常時内部レジスタのチェックをかけてます。
Re: (スコア:0)
func_1() 等関数呼び出しを平気で行っていますが、スタックに詰まれる等する戻り番地の内容の保証はどうしてるんですか?
Re: (スコア:0)
内容の保証をしたいのではなくて、
値が壊れる可能性の存在をチェックしたい(その可能性を検知したらそこで死んで欲しい)のでは?
おそらく、 kick_NMI() からは戻ってこない。
Re: (スコア:0)
そういうのは C で書いても意図が分かりにくいんで
アセンブリレベルでどういうことを意図しているのか
説明してください。
Re: (スコア:0)
if と elsif が混ざるのがいやなので
if (0) {
}
elsif (いっこめの条件) {
}
elsif (にこめの条件) {
}
else {
kick_NMI();
}
と書いています
大規模クラスタ (スコア:0)
こういった障害の起こりやすさにFIT(Failure In Time)という目安があるのですが、これは10^9時間におこる誤作動の回数です。
京の講習会の時に聞いたのですが、大規模なクラスタだと1ノードで10FITとかそのくらいのオーダーらしいです。詳しい数字は忘れましたが。ところで、10万ノードで100時間計算し、一度も誤作動を起こさない確率を上のFITから推定すると
(1 - 10^-8)^(10^6*10^2)
と、だいたい37%くらいになります。
京の実際のノードはこれよりもやや少ないですが、結構現実的な脅威ですね。
Re: (スコア:0)
それってMTBFの表現を変えただけ?
Re: (スコア:0)
In practice, the mean time between failures (MTBF, 1/λ) is often reported instead of the failure rate. This is valid and useful if the failure rate may be assumed constant – often used for complex units / systems, electronics – and is a general agreement in some reliability standards (Military and Aerospace). It does in this case only relate to the flat region of the bathtub curve, also called the "useful life period". Because of this, it is incorrect to extrapolate MTBF to give an estimate of the servic
Re: (スコア:0)
出典 [wikipedia.org] ぐらい示せよ。
それから頭の悪い俺にもわかるように、100文字ぐらいにまとめてくれ。
Re: (スコア:0)
システムの障害が部品の故障によって引き起こされると仮定したとき、システムの平均故障間隔は全部品の故障率(FIT数)の総和の逆数で期待されます。つまりMTBFを見積もるときに使われるものです。
10FITのノードが10万ノード集まって構成されていて、他の部品の故障は無いとすれば、
平均故障間隔=10^9/(10*100000)=1000時間と計算されます。実際にはソフト的なエラー(処理能力を超えてしまう入力がなされる確率とか)も足さないといけないはず。
もちろんこれは見込み値であって、実際のMTBF(平均故障間動作時間)は
ある特定期間中のMTBF=その期間中の総動作時間/総故障数
と定義されています。(JIS Z 8115) [kikakurui.com]
Re: (スコア:0)
10万ノードは10^5では…
計算し直すと約 90.5% になるようです。
テストなんて飾りです(真剣 (スコア:0)
某社製ケータイのテストをやったことがあったが「画像ファイルの読み込み・表示」のテストが雑すぎて笑った記憶がある。
・テスト画像を読み込んで正常に表示できること
・0バイトのファイルを開く際にエラーにできること
の二通りしかテスト項目がなかったんだよな。
せめて「ダウンロード中に回線が切れて途中までしかダウンロードできなかった画像の読み込み」をどうするかは考えなきゃダメでしょうにねぇ。
Re: (スコア:0)
壊れていていいからできる限り表示してほしいところ
一番困るのはエラーですね
つまり、何もしないのが一番です
Re: (スコア:0)
何もしない(デッドロック)
Re: (スコア:0)
テストに金はかけない、というメッセージです。
マジレスですが。
Re: (スコア:0)
設計として対策してある必要はもちろんありますが、
テストの際にその現象を確認する方法が困難なので
テスト項目からは外しているという可能性は
あるかも知れない。
とある銀行の勘定系システムで (スコア:0)
銀行の勘定系システムで、データベースから数値を持ってくるのに、DB側でで合計を出すクエリ投げた結果と、自分で単純なSELECT文で表を持ってきて加算した処理の結果を突合して検算する処理を作ってたことあるよ
以前、データベースが(本当に特定の条件下でだけど)集計を間違えることがあってから、そういう処理をいれたんだっけな
(逆に自分でSELECTしてくる側を改修その他で「バグを作り込む可能性がない」とも言い切れないので、その仕様は永続させてる)
ソフトエラー検知 (スコア:0)
ステートレスな関数だったら関数から抜ける時に入力変数を何度かフェッチして値不変性のチェックとか、再度実行して出力の同一性チェックするコードを自動的に挿入すれば、ソフトエラーを見過ごす可能性は大分減らせそう。
手で入れるのは良くあるけど。
ハードウェア側での訂正より良い点としては、後からより耐性が欲しくなった時にいくらでもチェックを余分にできるって点かな。その分遅くなるけど。
勘定系とかはそういうのやってないのかな。
整数のMSBにビットが立って大ある日突然大富豪になったりして。
あるいは、借金王になるかも。
パラノイアテストって何? (スコア:0)
https://www.google.co.jp/search?q=%2B%22%E3%83%91%E3%83%A9%E3%83%8E%E3... [google.co.jp]
ググったけど分からん。
Re: (スコア:0)
わしも初耳だけど、ソース [blogspot.jp]にあるBjarne Stroustrupのコメントから推測できる。
そのパラノイアテストはコンパイラーのメインループに仕掛けてある。もしソフトウェアかハードウェアに不具合があったならば、そのテストのうちのどれかは失敗するだろう。少なくとも一度、そのコードはCFrontをビルドするツールのコード生成のバグを発見した。思うに、すべての大規模なプログラムは、「不可能」なエラーを発見するための「パラノイアテスト」を含むべきである。
「ビルドするツールのコード生成のバグ」なら経験した人はそれなりに居るんじゃないか?
少なくとも「宇宙線が降ってきてメモリのビットが狂う」を経験した人よりは。
Re: (スコア:0)
一瞬カクつくのは結構深刻です。Androidではカクついて隣の項目をタップとか結構発生します。
Re: (スコア:0, 参考になる)
一方、OS Xは最初からずれていた
http://gigazine.net/news/20120208-mac-os-x-mouse-delay-32-milliseconds/ [gigazine.net]
Re: (スコア:0, 荒らし)
まったくAppleに関係ない記事でも無理やりAppleを叩く材料にする工作員さん、なんぼ貰ってるのか知りませんが毎度毎度ほんとにお疲れ様です。
# まさかタダでこんなアホみたいなことしてるわけじゃないよね?
Re: (スコア:0)
アレゲではないガチの信者の方はこのサイトへの書き込みをお控えください
Re:Apple信者にMS製品やGoogle製品を使わせる (スコア:1)
正直信者とか何とかうんざりです。2chだって今どきこんな言い方しないでしょう。
Re:Apple信者にMS製品やGoogle製品を使わせる (スコア:1)
> 正直信者とか何とかうんざりです。2chだって今どきこんな言い方しないでしょう。
ほんとにガチの人なんですね
怖いな
Re: (スコア:0)
だいたい罵倒芸はfjのほうが先だったしな。F-Secureやどっかの新聞社の件でまだ匿名だと思ってどーのこーの言ってるのは正直もう呆れ果てるしかない。