nabeshinによる
2007年10月29日 13時44分の掲載
カードは翌日から無効になる？部門より。
カードは翌日から無効になる？部門より。
Anonymous Coward曰く、
asahi.comの記事によると、12日に起きた自動改札機の障害は、無効カードデータの情報送信時に、境界バイト処理に失敗することが原因だったそうだ。
よくわからないのは記者の解説。意訳が入っているらしく数字が理解できないのだが、「85件増すごとに5件の割合で、余った2バイトの処理を忘れる」という引用があるので、ここの数字だけは表現が正しいと思われる。ちなみに、開発（納品？）元の日本信号からは、10月15日付けで簡単な報告が公開されおり、朝日新聞の記事はその詳細をインタビューしたものと思われる。
このバグ、どういう話だと思われますか？
この議論は賞味期限が過ぎたので、保存されている。
新たにコメントを書くことはできない。
|
|
本当に専門家？ (スコア:5, 興味深い)
この専門家の名前が知りたいものですね。
それとも専門家の言葉尻だけつまんでアサヒるかもしれませんが。
解析の結果、ミスにあたる部分が数行で”単純に見える”事はあっても実態はそんなに単純ではない事の方が多いと思うのですが実際のところはどうなのだろう？
＃構造は単純でも工程は複雑
あとコーディングミスと設計ミスと仕様記述書のミスは別物ですよね、専門家なら設計ミスなのか仕様書の書き方が曖昧で解釈が複数とれておきた事故なのかとかとか・・・位はご指導いただきたいものです。
Re:本当に専門家？ (スコア:2, 興味深い)
# 逆に、2と3を明確に分けるポイントはなんでしょう？
なんにせよ、しっかりvalidationのコードを書いていれば、実装～レビューの過程で考慮漏れとして見つかったでしょうね。
validationをそれなりに実装しながらの考慮漏れとしたとき、ユニットテストを実装者本人がやっていたなら、ユニットテストで見つかる可能性は低い。まぁ、テストの帽子にかぶり替えていれば、見つかる可能性も少しは上がりますか。
詳細なアルゴリズム/データ構造について、今の組み込みの現場では、どのくらいしっかりレビューするもんですかね？
エンタプライズ系の受託な世界では、そこまで全件を第三者がレビューする現場って、多くはないと思う……。
親コメント
Re:本当に専門家？ (スコア:2, 興味深い)
日本信号の発表では「データ数がある件数以上かつある条件下」で発生するバグだと言ってる。
Cで通信プログラムを書いたことがあれば分かるけど、特定の条件でのみ発生するメモリ破壊系のバグはテストで叩き出すのが困難。
この手のバグはコードレビューをすり抜けちゃうと、発覚する局面は事件になるときなんだよね。
こういうバグに対抗するためにPurify、BoundsCheckerなんかのお高い検査ツールがあるんだけど、使ってたのかな。
親コメント
Re:本当に専門家？ (スコア:2, 興味深い)
ウチも、客から
と言う依頼が来たことがありますが、もともとウチで作ったものではないので
と言ってみたら、
と、返事がきました。
発注元はそれなりに有名な SIer だったので、「あんなところでもツールは使わないのか」と思ったのですが。
fj.jokes出身:
親コメント
心当たり (スコア:4, おもしろおかしい)
ちょうど前日に定期の期限が切れたので、当日継続で買ったオレのせいでしょうか？
みんな頭がいいなぁ(棒読み) (スコア:4, おもしろおかしい)
私がこのコメントを
『85レス増えることに 5件だけ理解できて
余ったレス(理解できなかった80件)の、2行目以降読み飛ばす事だ』
#私には高度過ぎる
[注意]コメント主は大変叩かれ弱い性質です。優しく接してあげて下さい
～おもしろおかしい以外に興味はありません～
Re:みんな頭がいいなぁ(棒読み) (スコア:5, おもしろおかしい)
#私にも高度過ぎる
親コメント
推測 (スコア:3, 興味深い)
下位層のパケットが64Kバイト（ヘッダ17バイト＋ペイロード65518バイト）単位で、そのペイロードの中に（12バイト*ネガティブデータ5451件＋制御コード106バイト）があるという構造が見えてきます。
＞８５件増すごとに５件の割合で、余った２バイトの処理を忘れる
データが1件当たり12バイトなので、85件で1020バイト。おそらく、パケットをまたいだデータのバッファリング単位が1Kバイトなんでしょう。この時に何らかの原因でポインタの進め方を誤っていると想像されますが、「5件｣てのがよくわかりませんねぇ。
Re:推測 (スコア:4, 興味深い)
８５件増える間にコケるパターンが５つある。
それ以降も８５件単位で同じパターンを繰り返す、てなとこじゃない？
どちらかというとパケット云々の問題ではなく、
内部のテーブルの初期サイズが 64KB
溢れたら 1KB 単位で拡張、でも拡張するたびに特定の件数でエラー発生、
てことのような気がする。
親コメント
Re:推測 (スコア:3, 興味深い)
誤る件数が85件につき5件なので、5*12=60、処理単位は64byteなんじゃないでしょうか。
1KB拡張して64byteずつ処理するんだけれど、余りの分を考慮しようとして最後の64byteを捨ててしまうとか。
もしくは64KBを越えた場合の件数のカウントが、本当は65536byte無い(65518byte区切り)のに65536/12=5461から始まってておかしくなるとか。
親コメント
Re:推測 (スコア:2, 興味深い)
通信単位と処理単位のパケットサイズが違う場合って、動的に組み立ててカーソルをずらしていくようなものなので、バグが入りやすいところではあります。
親コメント
Re:推測 (スコア:2, 興味深い)
実は最後の 2byte は終了コードになっていて、
開始ヘッダ 104byte + データ部 12N byte + 終了コード 2 byte
みたいな構造になっていた。
データが 5451件 に収まる場合には 65536byte 確保し、
以後足りない場合には 64byte ずつ追加してメモリを補った。
そのサイズの計算の際に、残り 2byte 分の容量の計算を忘れて、
104 + 12N byte 確保すればいいものと勘違いしていた。
そのために、
5451 + 7 件のデータ => 65536 + 66byte 確保すべきところを 2byte 確保し忘れる。
5451 + 23件のデータ => 65536 + 258byte 確保すべきところを 2byte 確保し忘れる。
5451 + 38件のデータ => 65536 + 450byte 確保すべきところを 2byte 確保し忘れる。
5451 + 54件のデータ => 65536 + 642byte 確保すべきところを 2byte 確保し忘れる。
5451 + 70件のデータ => 65536 + 734byte 確保すべきところを 2byte 確保し忘れる。
5451 + 86件のデータ => 65536 + 926byte 確保すべきところを 2byte 確保し忘れる。
... 以後 5458 + 16k ( k = 0, 1, 2,...) ごとに同様のことが起きる。
その際に最後の（確保されていない）終了コードを読み書きする際に
segmentation fault になって落ちる、という話ではないか。
おそらく 12日のデータは丁度 5451 + 86 = 5537件のデータがあって、
見事合致してしまった。
それまでに同様の現象が 5 回起きる可能性があったのだが、
見事合致しないで来ていた、ということでしょう。
85件中5件という奇妙な数字はこの辺りから出てきたのであろうと。
# なかの人ではないのでID
親コメント
徐々に意訳された結果 (スコア:3, おもしろおかしい)
次にそれを読んだ上司が専門用語だらけだから分かりやすく書き直せと指示されて新しい報告書ができます。
それが上長に回ったとき、ここはこうじゃないだろう？！、更に報告書が改定されます。
それが役員に回ったとき、ここはこうだろう？と更に報告書が改定されます。
それを読んだ新聞社の担当は、一般の人には分かりにくいよねと自分なりの解釈が入ります。
さらに編集長が校閲して、ここが・・・
こうして出てきた記事は、もはやなんだか
Re:徐々に意訳された結果 (スコア:4, すばらしい洞察)
「２」バイト よりも 日本語「１」文字 と書いた方が、
より小さなミスであの大きな騒ぎが起こされたかのように印象づけることができます。
そのビット数が日本語の文字を表現するかどうかという議論に意味などありません。
親コメント
特定の事実を表してるのではない (スコア:2, すばらしい洞察)
この表現の意味って、タバコ１箱分とか東京ドーム何杯とか、一般人に説明するための概算での例えの意味だろ。
文章として特定の事実を指すのに「分のデータ量」、分の量とは言わない。
親コメント
分割パケットの再構築ミス? (スコア:2, 参考になる)
で、受信側が分割パケットを再構築する処理に問題があって変なところで切れるとうまく処理できなかったと。
＃という風に読めた
ネガデータのローディング (スコア:1)
以下、素人考えで申し訳ない。
本論とは関係ないけど、毎朝の立ち上げの際、改札機や窓口処理機がネガデータの最新版を取り込む、とあるけれど、これではネガデータが増えたとき(稼動年月を経たとき、利用者が増えたとき)にデータのローディングで障害起きないかな。あるいはデータのローディングに時間がかかって、朝の立ち上げを早くしなくちゃいけないとか、夜のクロージング(あるのかそんな処理？)と朝の立ち上げがクロスするとか、朝の立ち上げに間に合わなくなるようなことにならないかな。
一定の条件に合致するものはローディングの対象とならないようになっているので大丈夫、とかデータ件数には想定があるのかな。
コタツ出したら負けかなと思ってる。 つ [twitter.com]
Re:膨大サイズのな1レコードですね。 (スコア:1, すばらしい洞察)
計算上は1レコードは12バイトでしょ。
親コメント
Re:前のストーリーで、 (スコア:3, 参考になる)
このへんでしょうか。
親コメント
Re:わずか1文字分？ (スコア:1, すばらしい洞察)
親コメント
Re:わずか1文字分？ (スコア:4, おもしろおかしい)
もし50文字分のデータ処理を間違ってたら全国民の足に影響してたかもしれないですね.
親コメント
Re:わずか1文字分？ (スコア:2, すばらしい洞察)
とんでもないことになると思います。
わずか1文字だけと侮るなかれ。
親コメント