パスワードを忘れた? アカウント作成
12604271 story
プログラミング

スラドに聞け:あなたがオススメするアプリケーション・パラノイアテストは? 62

ストーリー by hylom
そんなものがあったのか 部門より
m_nukazawa 曰く、

C++コンパイラの元祖とされている「Cfront」がリリースされてから30年が過ぎたことを記念して、Cfrontのソースコードをコード静的解析ツールであるPVS-Studioで解析したという話が公開されている(本の虫)。

この記事自体も大変興味深いのだが、タレコミ主が特に惹かれたのが、「パラノイアテスト」だ。引用されていたツイートによると、Google Chromeには通常ではありえないビット異常をチェックしてアプリケーションのバグと区別するために「パラノイアテスト」が搭載されているらしい。

タレコミ主は不勉強故か、パラノイアテストの確立された標準的な手法について書かれた書籍や文献に心当たりがない。また、Chrome以外で参考になるオープンソースプロジェクトを探すのも骨が折れそうだ。

そこで聞きたいのだが、スラドの諸兄は自分の関わったプロジェクトで、パラノイアテストを見かけたり、実装したことがおありだろうか。

心当たりや実際の知見、あるいは又聞きで聞いた根も葉もない噂などでも構わない。パラノイアテストについて思うがままに語り合って頂ければ幸いである。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2015年12月03日 2時32分 (#2927600)

        if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
            goto fail;
            goto fail; // 念のためもう一回

  • by miyuri (33181) on 2015年12月03日 6時02分 (#2927619) 日記

    コード部分のハッシュを適宜算出して、変化が有れば殺すっていうのは、ある種の方面ではよくあること。

  • by Anonymous Coward on 2015年12月02日 16時44分 (#2927257)

    幸福であるかを調べればいいのか?

    • by Anonymous Coward

      幸福に決まってるじゃないですか。幸福は義務ですよ、市民。

    • by Anonymous Coward

      露出狂のサンタが出てきたりするのかも

      #あろ先生もなんか4コマの人になっちゃったなぁ…

      • by Anonymous Coward

        あれはぱらのい屋じゃないですか。

      • by Anonymous Coward

        雲界の旅人の続き描かないかなあ

  • by Anonymous Coward on 2015年12月02日 18時53分 (#2927369)

    制御機器のプログラムだと、物理メモリアクセスに対して常時パリティチェックをかけるような専用タスクが走らせるのは
    ごく普通にありますよ。

    あと、たとえば

    if a==1 {
            // aが1のとき
            func_1();

    } else if a!=1 {
            // aが1以外のとき
            func_2();

    } else {
            // 正常ならここは通らないはず
            kick_NMI();
    }

    などというコーディングはフェイルセーフプログラミングでは常識と思っているのですが、
    このくらいなら普通のプログラマでも普通にやるのでは?

    #もちろん実際にはオプティマイズでコード削除されないようにしますが

    • by uxi (5376) on 2015年12月02日 23時24分 (#2927544)

      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
      親コメント
      • by Anonymous Coward on 2015年12月02日 23時46分 (#2927550)

        タレコミのツイート [twitter.com]

        「宇宙線が降ってきてメモリのビットが狂う」「ハードウェアのバグでメモリのビットが狂う」というのは非常にまれな現象だけど、Chromeくらいのユーザ数規模になるとけっこう日常的に起きます。なのでChromeで走ってるGCには、それらのビット異常を検知する機構をわざわざ入れてます。

        実際の仕組みは知りませんが、プログラマが意識しなくてもGCがやってくれるところがポイントなんですかね。

        親コメント
        • by Anonymous Coward

          ノードの管理情報に冗長性持たせてGCでチェックしてるとかその程度の話じゃない?

      • サンプルコードが(擬似コードで)言いたい事のわりにはしょってるのでコメントが伸びているような。

        想像するに、RAMは化ける可能性があるけどROMやCPUはハード的に保護して信頼性高くしてあって、というようなシステムのようだけど、RAMから呼んだ値はレジスタに置いて if 文を通るようにコーディングするんではないかな。普通ならやれることもできない、あれこれ制約されたコーディング規約もついて。

        もしCPU/ROMもずっこけるというのなら、同一構成のシステム複数で多数決するとかなんとかしてやるだろうからif文でどうこうという話にはならないだろうし。

        親コメント
        • by Anonymous Coward

          ・信頼できないデータを読んですぐ分岐するというのが理解できない
          ・もしa==1とa!=1でaを二回読んで欲しいというのなら、オプティマイズがどうのというのが理解できない

    • by Anonymous Coward

      クセにしといた方がいいですね。
      ステートマシンの未定義ステートで元に戻すorリセット掛ける
      # ムーアマシン ミーリマシン? 昔のことは忘れた

    • by Anonymous Coward

      条件式がa==1とa!=1ならそんなことしませんよ
      a!=1と書くこと自体がバグの元

      switch文の場合、行くはずのないdefaultに行くバグはあるから、それとごっちゃになってませんか

      • by Anonymous Coward on 2015年12月02日 20時36分 (#2927440)

        どうしてもこう書きたいならaはvolatileにしないといけないはずですが

        親コメント
        • by Anonymous Coward

          > #もちろん実際にはオプティマイズでコード削除されないようにしますが

          • by Anonymous Coward

            オプティマイズの問題だと思っているところが、問題なんです

          • by Anonymous Coward

            何を言いたいのかわかりませんが、

            aがvolatileだろうが、volatileでなかろうがそういう問題ではなく、
            a==1とa!=1が同時に成立する場合があり得るので、
            そういう場合には、
            > // 正常ならここは通らないはず
            > kick_NMI();
            を実行させる。

            そんな事情わからないコンパイラが、勝手にオプティマイズで消す可能性があるので、
            >#もちろん実際にはオプティマイズでコード削除されないようにしますが
            ってことでしょ。

            >条件式がa==1とa!=1ならそんなことしませんよ
            >a!=1と書くこと自体がバグの元
            とか、

            >どうしてもこう書きたいならaはvolatileにしないといけないはずですが
            とか、論外。
            ビットが安定していることが前提の世界の話ではない。

            • by Anonymous Coward

              > a==1とa!=1が同時に成立する場合があり得る

              同時はおかしいだろ。

              • by Anonymous Coward

                ソースレベルだとそうだけど、バイナリレベルだとどちらかの「1」のビットが乱れればあり得る。

              • by Anonymous Coward


                cmp a, #1
                beq label1
                bne label2

                仮に上のような例で両方の条件分岐が成立するとしても、同時に判定しないので先に判定したほうが優先されるだけ。

            • by Anonymous Coward

              > aがvolatileだろうが、volatileでなかろうがそういう問題ではなく、
              > a==1とa!=1が同時に成立する場合があり得るので、

              RAMが化けるという話であれば、RAMをそのつど読むか一度読んだ値を使いまわすかは重要な話では?

    • by Anonymous Coward

      IC内のロジック設計でも同様です。
      信頼性を確保する必要がある用途では、常時内部レジスタのチェックをかけてます。

    • by Anonymous Coward

      func_1() 等関数呼び出しを平気で行っていますが、スタックに詰まれる等する戻り番地の内容の保証はどうしてるんですか?

      • by Anonymous Coward

        内容の保証をしたいのではなくて、
        値が壊れる可能性の存在をチェックしたい(その可能性を検知したらそこで死んで欲しい)のでは?

        おそらく、 kick_NMI() からは戻ってこない。

    • by Anonymous Coward

      そういうのは C で書いても意図が分かりにくいんで
      アセンブリレベルでどういうことを意図しているのか
      説明してください。

    • by Anonymous Coward

      if と elsif が混ざるのがいやなので

      if (0) {
      }
      elsif (いっこめの条件) {
      }
      elsif (にこめの条件) {
      }
      else {
        kick_NMI();
      }

      と書いています

  • by Anonymous Coward on 2015年12月02日 16時50分 (#2927264)

    こういった障害の起こりやすさにFIT(Failure In Time)という目安があるのですが、これは10^9時間におこる誤作動の回数です。

    京の講習会の時に聞いたのですが、大規模なクラスタだと1ノードで10FITとかそのくらいのオーダーらしいです。詳しい数字は忘れましたが。ところで、10万ノードで100時間計算し、一度も誤作動を起こさない確率を上のFITから推定すると

    (1 - 10^-8)^(10^6*10^2)

    と、だいたい37%くらいになります。

    京の実際のノードはこれよりもやや少ないですが、結構現実的な脅威ですね。

    • by Anonymous Coward

      それってMTBFの表現を変えただけ?

      • by Anonymous Coward

        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

        • by Anonymous Coward

          出典 [wikipedia.org] ぐらい示せよ。
          それから頭の悪い俺にもわかるように、100文字ぐらいにまとめてくれ。

      • by Anonymous Coward

        システムの障害が部品の故障によって引き起こされると仮定したとき、システムの平均故障間隔は全部品の故障率(FIT数)の総和の逆数で期待されます。つまりMTBFを見積もるときに使われるものです。
        10FITのノードが10万ノード集まって構成されていて、他の部品の故障は無いとすれば、
        平均故障間隔=10^9/(10*100000)=1000時間と計算されます。実際にはソフト的なエラー(処理能力を超えてしまう入力がなされる確率とか)も足さないといけないはず。
        もちろんこれは見込み値であって、実際のMTBF(平均故障間動作時間)は
        ある特定期間中のMTBF=その期間中の総動作時間/総故障数
        と定義されています。(JIS Z 8115) [kikakurui.com]

    • by Anonymous Coward

      10万ノードは10^5では…
      計算し直すと約 90.5% になるようです。

  • by Anonymous Coward on 2015年12月02日 19時52分 (#2927406)

    某社製ケータイのテストをやったことがあったが「画像ファイルの読み込み・表示」のテストが雑すぎて笑った記憶がある。

    ・テスト画像を読み込んで正常に表示できること
    ・0バイトのファイルを開く際にエラーにできること

    の二通りしかテスト項目がなかったんだよな。

    せめて「ダウンロード中に回線が切れて途中までしかダウンロードできなかった画像の読み込み」をどうするかは考えなきゃダメでしょうにねぇ。

    • by Anonymous Coward

      壊れていていいからできる限り表示してほしいところ
      一番困るのはエラーですね
      つまり、何もしないのが一番です

      • by Anonymous Coward

        何もしない(デッドロック)

    • by Anonymous Coward

      テストに金はかけない、というメッセージです。

      マジレスですが。

    • by Anonymous Coward

      設計として対策してある必要はもちろんありますが、
      テストの際にその現象を確認する方法が困難なので
      テスト項目からは外しているという可能性は
      あるかも知れない。

  • by Anonymous Coward on 2015年12月03日 0時08分 (#2927556)

    銀行の勘定系システムで、データベースから数値を持ってくるのに、DB側でで合計を出すクエリ投げた結果と、自分で単純なSELECT文で表を持ってきて加算した処理の結果を突合して検算する処理を作ってたことあるよ

    以前、データベースが(本当に特定の条件下でだけど)集計を間違えることがあってから、そういう処理をいれたんだっけな
    (逆に自分でSELECTしてくる側を改修その他で「バグを作り込む可能性がない」とも言い切れないので、その仕様は永続させてる)

  • by Anonymous Coward on 2015年12月03日 1時05分 (#2927568)

    ステートレスな関数だったら関数から抜ける時に入力変数を何度かフェッチして値不変性のチェックとか、再度実行して出力の同一性チェックするコードを自動的に挿入すれば、ソフトエラーを見過ごす可能性は大分減らせそう。
    手で入れるのは良くあるけど。

    ハードウェア側での訂正より良い点としては、後からより耐性が欲しくなった時にいくらでもチェックを余分にできるって点かな。その分遅くなるけど。

    勘定系とかはそういうのやってないのかな。
    整数のMSBにビットが立って大ある日突然大富豪になったりして。
    あるいは、借金王になるかも。

  • by Anonymous Coward on 2015年12月03日 8時23分 (#2927644)
    • by Anonymous Coward

      わしも初耳だけど、ソース [blogspot.jp]にあるBjarne Stroustrupのコメントから推測できる。

      そのパラノイアテストはコンパイラーのメインループに仕掛けてある。もしソフトウェアかハードウェアに不具合があったならば、そのテストのうちのどれかは失敗するだろう。少なくとも一度、そのコードはCFrontをビルドするツールのコード生成のバグを発見した。思うに、すべての大規模なプログラムは、「不可能」なエラーを発見するための「パラノイアテスト」を含むべきである。

      「ビルドするツールのコード生成のバグ」なら経験した人はそれなりに居るんじゃないか?
      少なくとも「宇宙線が降ってきてメモリのビットが狂う」を経験した人よりは。

typodupeerror

吾輩はリファレンスである。名前はまだ無い -- perlの中の人

読み込み中...