改札トラブルは境界処理のミスでハングアップ 77
ストーリー by nabeshin
カードは翌日から無効になる？ 部門より
カードは翌日から無効になる？ 部門より
Anonymous Coward曰く、
asahi.comの記事によると、12日に起きた自動改札機の障害は、無効カードデータの情報送信時に、境界バイト処理に失敗することが原因だったそうだ。
よくわからないのは記者の解説。意訳が入っているらしく数字が理解できないのだが、「85件増すごとに5件の割合で、余った2バイトの処理を忘れる」という引用があるので、ここの数字だけは表現が正しいと思われる。ちなみに、開発（納品？）元の日本信号からは、10月15日付けで簡単な報告が公開されおり、朝日新聞の記事はその詳細をインタビューしたものと思われる。
このバグ、どういう話だと思われますか？
本当に専門家？ (スコア:5, 興味深い)
この専門家の名前が知りたいものですね。
それとも専門家の言葉尻だけつまんでアサヒるかもしれませんが。
解析の結果、ミスにあたる部分が数行で”単純に見える”事はあっても実態はそんなに単純ではない事の方が多いと思うのですが実際のところはどうなのだろう？
＃構造は単純でも工程は複雑
あとコーディングミスと設計ミスと仕様記述書のミスは別物ですよね、専門家なら設計ミスなのか仕様書の書き方が曖昧で解釈が複数とれておきた事故なのかとかとか・・・位はご指導いただきたいものです。
Re:本当に専門家？ (スコア:1, すばらしい洞察)
# だって「バグ」は「間違っている所」だけにフォーカスを当てるからね。
# 「間違っている所を見つける」コストは無視される。
テストが無かったのですから、「想定外」だったか「締め切りが来ちゃった」か最低限でもどちらか一方が起こったことは確実ですし、それらが起こった要因は…うーん。
いやいや。全部一度に作らざるを得ないぐらい突貫工事状態になれば、この3つは同じものです。
「コーディングしたとおりに設計図を描き、仕様書を記述する。
なぜなら、発注側が仕様書を書けないから。」
なんてのは日本ではよくある話。
Re:本当に専門家？ (スコア:0)
あとは「コードが仕様ですから･･･」とか？
Re:本当に専門家？ (スコア:0)
１．エラーログを見る
２．そのエラーを出しうるコードを洗い出す
３．そのコードの妥当性を検証する
という過程で調べると思いますが、今回の場合、当日のうちに3の部分で不具合が見つかったわけで、本来ならコードレビューで潰されてしかるべきミスのはず。
コードレビューをすり抜けたとしてもユニットテストでは絶対に潰されていないといけないミスです。
Re:本当に専門家？ (スコア:2, 興味深い)
# 逆に、2と3を明確に分けるポイントはなんでしょう？
なんにせよ、しっかりvalidationのコードを書いていれば、実装～レビューの過程で考慮漏れとして見つかったでしょうね。
validationをそれなりに実装しながらの考慮漏れとしたとき、ユニットテストを実装者本人がやっていたなら、ユニットテストで見つかる可能性は低い。まぁ、テストの帽子にかぶり替えていれば、見つかる可能性も少しは上がりますか。
詳細なアルゴリズム/データ構造について、今の組み込みの現場では、どのくらいしっかりレビューするもんですかね？
エンタプライズ系の受託な世界では、そこまで全件を第三者がレビューする現場って、多くはないと思う……。
Re:本当に専門家？ (スコア:2, 興味深い)
日本信号の発表では「データ数がある件数以上かつある条件下」で発生するバグだと言ってる。
Cで通信プログラムを書いたことがあれば分かるけど、特定の条件でのみ発生するメモリ破壊系のバグはテストで叩き出すのが困難。
この手のバグはコードレビューをすり抜けちゃうと、発覚する局面は事件になるときなんだよね。
こういうバグに対抗するためにPurify、BoundsCheckerなんかのお高い検査ツールがあるんだけど、使ってたのかな。
Re:本当に専門家？ (スコア:2, 興味深い)
ウチも、客から
と言う依頼が来たことがありますが、もともとウチで作ったものではないので
と言ってみたら、
と、返事がきました。
発注元はそれなりに有名な SIer だったので、「あんなところでもツールは使わないのか」と思ったのですが。
fj.jokes出身:
Re:本当に専門家？ (スコア:1)
ここで気づかないと…
心当たり (スコア:4, おもしろおかしい)
ちょうど前日に定期の期限が切れたので、当日継続で買ったオレのせいでしょうか？
Re:心当たり (スコア:0)
自意識過剰です。
お前か!お前の所為で!!! (スコア:0)
Re:お前か!お前の所為で!!! (スコア:1)
みんな頭がいいなぁ(棒読み) (スコア:4, おもしろおかしい)
私がこのコメントを
『85レス増えることに 5件だけ理解できて
余ったレス(理解できなかった80件)の、2行目以降読み飛ばす事だ』
#私には高度過ぎる
[注意]コメント主は大変叩かれ弱い性質です。優しく接してあげて下さい
～おもしろおかしい以外に興味はありません～
Re:みんな頭がいいなぁ(棒読み) (スコア:5, おもしろおかしい)
#私にも高度過ぎる
Re:みんな頭がいいなぁ(棒読み) (スコア:0)
仮復旧でしばらく運用ってどうなることやらと思ったけどあんまり拡大しなくてよかった
推測 (スコア: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
Re:推測 (スコア:1)
5451 + 7 件のデータ => 65536 + 66byte 確保すべき
5451 + 23件のデータ => 65536 + 258byte 確保すべき
5451 + 39件のデータ => 65536 + 450byte 確保すべき
5451 + 55件のデータ => 65536 + 642byte 確保すべき
5451 + 71件のデータ => 65536 + 734byte 確保すべき
5451 + 87件のデータ => 65536 + 926byte 確保すべき
12日のデータは 5451 + 87 = 5538件あったのでしょう。
データが初めて 65536byte を越えるのは、5453件目（65542byte）で、
ここから数えて 86 件目となります。
それ以前の 85件の内の 5パターンにはたまたま合致しなかった、
ということだと思います。違うかな。
Re:推測 (スコア:0)
「2バイト」は不明。
徐々に意訳された結果 (スコア:3, おもしろおかしい)
次にそれを読んだ上司が専門用語だらけだから分かりやすく書き直せと指示されて新しい報告書ができます。
それが上長に回ったとき、ここはこうじゃないだろう？！、更に報告書が改定されます。
それが役員に回ったとき、ここはこうだろう？と更に報告書が改定されます。
それを読んだ新聞社の担当は、一般の人には分かりにくいよねと自分なりの解釈が入ります。
さらに編集長が校閲して、ここが・・・
こうして出てきた記事は、もはやなんだか
Re:徐々に意訳された結果 (スコア:0)
過去に何度も同じ事象が発生してるでしょ？
Re:徐々に意訳された結果 (スコア:0)
「亡くなった時には脳みそだけでも凍結保存しろよ」とか、思わず考えちゃいますよね。
＃作品のファンであって、作家のファンではないのでAC
Re:徐々に意訳された結果 (スコア:0)
「自分で書く」
# 思い通りのものが書けない時は、監禁なり脳みそ冷凍なりお好きにどうぞ
Re:徐々に意訳された結果 (スコア:4, すばらしい洞察)
「２」バイト よりも 日本語「１」文字 と書いた方が、
より小さなミスであの大きな騒ぎが起こされたかのように印象づけることができます。
そのビット数が日本語の文字を表現するかどうかという議論に意味などありません。
特定の事実を表してるのではない (スコア:2, すばらしい洞察)
この表現の意味って、タバコ１箱分とか東京ドーム何杯とか、一般人に説明するための概算での例えの意味だろ。
文章として特定の事実を指すのに「分のデータ量」、分の量とは言わない。
Re:徐々に意訳された結果 (スコア:0)
当該のデータに日本語が関係するところがあるようには見えませんが。
UTF-8 環境だと面倒がって一文字 4bytes/char で余分に割り当ててるなあ。
:wq
Re:徐々に意訳された結果 (スコア:1)
TomOne
Re:徐々に意訳された結果 (スコア:0)
分割パケットの再構築ミス? (スコア:2, 参考になる)
で、受信側が分割パケットを再構築する処理に問題があって変なところで切れるとうまく処理できなかったと。
＃という風に読めた
Re:分割パケットの再構築ミス? (スコア:1)
fj.jokes出身:
Re:分割パケットの再構築ミス? (スコア:1)
# 根こそぎ新品なんだから v6 でいいじゃん。
----
fj.jokes は我が海
fjの教祖様
Re:分割パケットの再構築ミス? (スコア:1)
========================================================
fjの教祖様に目をつけられてしまった。がくがくぶるぶる
fj.jokes出身:
ネガデータのローディング (スコア:1)
以下、素人考えで申し訳ない。
本論とは関係ないけど、毎朝の立ち上げの際、改札機や窓口処理機がネガデータの最新版を取り込む、とあるけれど、これではネガデータが増えたとき(稼動年月を経たとき、利用者が増えたとき)にデータのローディングで障害起きないかな。あるいはデータのローディングに時間がかかって、朝の立ち上げを早くしなくちゃいけないとか、夜のクロージング(あるのかそんな処理？)と朝の立ち上げがクロスするとか、朝の立ち上げに間に合わなくなるようなことにならないかな。
一定の条件に合致するものはローディングの対象とならないようになっているので大丈夫、とかデータ件数には想定があるのかな。
Re:ネガデータのローディング (スコア:1, すばらしい洞察)
仕組みを理解してからコメント書いた方がいいよ。
前のストーリーで、 (スコア:0)
俺も中のヒトに聞いたけど、口止めされたので既に出てる情報を元に話したい。
Re:前のストーリーで、 (スコア:3, 参考になる)
このへんでしょうか。
Re:前のストーリーで、 (スコア:0)
http://srad.jp/article.pl?sid=07/10/12/016240 [srad.jp]
どのコメントのことでしょう？
膨大サイズのな1レコードですね。 (スコア:0)
＞このバグ、どういう話だと思われますか？
６万５５１８バイトと言う膨大な値を1レコードとして扱うと言うのは
”設計のバグ”の話でしょうね。
突っ込みはいらないですか、そうですか。
Re:膨大サイズのな1レコードですね。 (スコア:1, すばらしい洞察)
計算上は1レコードは12バイトでしょ。
Re:膨大サイズのな1レコードですね。 (スコア:0)
Re:膨大サイズのな1レコードですね。 (スコア:0, おもしろおかしい)
数百MBなので、確かにでかいです。
んと (スコア:0, 余計なもの)
http://itpro.nikkeibp.co.jp/article/NEWS/20071015/284540/ [nikkeibp.co.jp]
JR東日本の自動改札機トラブル、16日までにプログラム改修を完了
http://internet.watch.impress.co.jp/cda/news/2007/10/15/17180.html [impress.co.jp]
わずか1文字分？ (スコア:0, すばらしい洞察)
>「極めて単純なプログラムミス」と専門家が指摘する欠陥は、のべ７２７駅、２６０万人の足に影響する事態に発展した。
わずか１文字分のデータの処理を誤っただけで２６０万人もの足に影響するんだから
・ソフトウェアの品質保証のための費用
・ソフトウェアの品質保証のためのソフトウェアエンジニアに対する人件費
について政府を頭にまじめに考えるべきなんじゃないの？
コードの量と拘束時間と納入期限を基準に評価して給料出してて質が落ちるのは偽装食品だけじゃないぜ
Re:わずか1文字分？ (スコア:4, おもしろおかしい)
もし50文字分のデータ処理を間違ってたら全国民の足に影響してたかもしれないですね.
Re:わずか1文字分？ (スコア:2, すばらしい洞察)
とんでもないことになると思います。
わずか1文字だけと侮るなかれ。
Re:わずか1文字分？ (スコア:1, すばらしい洞察)
Re:わずか1文字分？ (スコア:0)
そうでもしないと多くの「ソフトウェアエンジニア」は給料をもらえないのではないか？