大日本印刷のETCカードにバグ 60
ストーリー by wakatono
if(ETCUseCount==200+99*n){error();} 部門より
if(ETCUseCount==200+99*n){error();} 部門より
saitoh 曰く、 "大日本印刷製造のETCカードに不具合があり、利用しているクレジット会社では順次交換するとのこと。 出光カードからのアナウンス 。
ゲートと通信するETC機能そのものの不具合ではなく、カードローカルな機能のソフトウェアのバグのようだ。音声機能や液晶ディスプレイのついたETC車載装置では、200,299,398,497・・・回目にETCを使うと、実際の利用額と異なる金額がアナウンス/表示されることがあるらしい。 ブザーとランプしかない安価な車載機ではバグは発現しない模様。
出光ETCカードの場合、トラブルが起きていない顧客に関しては来年1月下旬から交換を開始するとのこと。車載機がエラーになってETCが利用不能になる症状が出ている顧客に関してはすぐに交換してくれるそうだ。 なお、出光以外で大日本のETCカードを使っているカード発行会社がどこなのか調べてみたが、不明。"
規則性はすぐにわかったが、なぜそうなったのだろう…
VIEWカード (スコア:2, 興味深い)
OMC-ETCも (スコア:1, 興味深い)
Re:OMC-ETCも (スコア:1, 興味深い)
順次交換カード発送とのこと 銀行系は利用者多いだろうなぁ。
大日本印刷の中の人は大変だなこりゃ（笑
Re:OMC-ETCも (スコア:2, 参考になる)
ついでにデザインまで変わりました。
/* なんだかんだと、すすむしかない */
もしかして… (スコア:2, 参考になる)
#define RIREKI_LEN 2048
char rireki[RIREKI_MAX][RIREKI_LEN];
i=count;
while(i>=RIREKI_MAX){
i-=100; //本来ならRIREKI_MAXとすべき。
}
strncpy(rireki[i], src, RIREKI_LEN-1); //本来なら iではなくi-1を指定すべき
rireki[i][RIREKI_LEN-1]=0;
//101+99*n(n=1～)でメモリオーバフローして…
みたいなドジカマしたのでは…
// %を使わないのはわざとです。開発はアセンブリでしょうけど、
// Cでしか表現できませんでしたorz
# rm -rf ./.
Re:もしかして… (スコア:0)
＞// %を使わないのはわざとです。開発はアセンブリでしょうけど、
ここで言うアセンブリというのはどういうものでしょう？
Re:もしかして… (スコア:1)
# rm -rf ./.
Re:もしかして… (スコア:0)
つーか、いわゆるところのアセンブリ言語でそ？普通わかりそうなものだが。
アセンブラ言語やアセンブラと呼ばれることもあるし、個人的にもそう呼ぶことがあるけど、機械語翻訳ツールとしてのアセンブラと区別する必要のある文脈ではアセンブリ言語のことをアセンブラとは絶対に言わない。
間違えました (スコア:1, おもしろおかしい)
200,299,398,497・・・回目にETCを使うと
一生のうちに一度も起こるかどうかのバグに対応しただなんて、ETCカードの中の人も大変だなぁ、と思ってしまいました。
いや、単にカンマを桁区切り文字だと誤解した(二千億回)だけの話なんですがね。
Re:間違えました (スコア:1)
私も思った口ですorz
200回目,299回目,398回目,497回目・・・回目にETCを使うと
or
200、299、398、497・・・回目にETCを使うと
だと読み間違えなかったと主張してみる。
# この親レスなかったらそのまま話を広めてたと思うと。。。ガクガク
## そうか、4桁まで書いておいてもいいなぁ。多くなるけど。
---にょろ～ん
Re:間違えました (スコア:1)
200,299,398,497÷75=2670658646.6267
2670658646.6267÷365=7316873.0044567
7316873.0044567÷24=304869.70851903
304869.70851903÷60=5081.1618086505
だいたい一分間に5081回くらいETCの前を通過すると死ぬ頃にはそのバグに出会えそうです。
＃計算あってる？間違ってる？
Re:間違えました (スコア:2, 興味深い)
ETCの前を二回（入り口と出口）通過しないと課金されません。
今回のは出口のETC通過の際の課金情報のバグです。
したがって、必要なETC前通過回数はその倍です。
＃閏年とかの無粋な突っ込みは無しにしてもこれは見逃せません。：）
＃ついでに、日本の高速道路のICの平均間隔は10km [google.co.jp]なので
＃1分で10kmを5081回突っ切るのは秒速800kmを越え、実に光速の0.3%にもなります。
Re:間違えました (スコア:1)
確かに首都高なんかもそうですね。
＃って、このモードの時にも出現するのだろうか？このバグは。
Re:間違えました (スコア:1)
Re:間違えました (スコア:1)
車載機または車とセットではないです。
なので、運転できなくてもETCカードが作れれば使用可能なはず。
---
「萌え」「美少女」「メイド」に現実逃避してはいけませんか、そうですか。
人事を半分尽くして天命を待つ
Re:間違えました (スコア:0)
カンマじゃなくてスラッシュで書いてくれれば間違えなかったのに。
Re:間違えました (スコア:2, すばらしい洞察)
スペースの有無で，桁区切りのカンマか単語区切りのカンマか，区別つくわな．
Re:間違えました (スコア:1)
Re:間違えました (スコア:0)
個人的にはどちらでも良い。ただし、スラッシュの後にピリオドを忘れるな。
Re:間違えました (スコア:0)
Re:間違えました (スコア:1)
ってことは、1回使うたびに約30万回エラーが起きるのか？！
Re:間違えました (スコア:1)
200/299
------- = 0.8352800793 では．．．
398/497
#違うのか。
Re:間違えました (スコア:0)
Re:間違えました (スコア:0)
これだけデカイ数の二進数電卓ってあるんでしょうか(笑)
しかしながら忙しいのに (スコア:1)
なぜ、この頻度の上がるときに限って判明するのやら…
続出しないことを祈ってます
#そういうことなのでID
#ICカードにもプログラムが載ってるんだ…スゴイ
--- *pucString
規則性 (スコア:0, フレームのもと)
Re:規則性 (スコア:1)
Re:規則性 (スコア:0)
Re:規則性 (スコア:0)
Re:規則性 (スコア:0)
199回までは別カウンタで回ってる? それも変な仕様だな。
やっぱ分からんわこれ。部門名みたいに明示的に200+99*n
とかいう判定条件が実装されてるのかなぁ。
Re:規則性 (スコア:2, 興味深い)
２００になると前１００個分を保存だかずらすだかして、次に２００個使うまでバッファのポインタを前１００個目にずらす。
この時にずらす位置を間違って、ずらした後に読込んだの値がずれる。
履歴があるのかどうか、ETCを使ってないから分からん。。。。
Re:規則性 (スコア:1)
次の１００回を数えるためのカウンタの初期値だかを間違う。
それで９９回目に再度・・・
どうだかな
Re:規則性 (スコア:4, 興味深い)
それを実現するために、2つの100回分の履歴領域を持ち、それを交互に利用する。
100個の領域のうち、最初の一つはバッファが溢れた場合には積算金額を保持する領域として使用。
rireki1[100];
rireki2[100];
として、rireki1[99]まで使えば次にrireki2を使用し、rireki2[99]まで使えばrireki1の0～99を合計してrireki1[0]に入れ、rireki1[1]～rireki1[99]は0クリアする。
こうしておけば、積算金額を知りたい時には、全バッファ領域200個sumすれば算出できる。
また、今回利用金額を書き込むべき領域は、現在利用中バッファの金額が0になっている最初の所という条件で知る事ができる。
この手のカードでは、おそらく永久記憶にはフラッシュを使っているので、カウンタや積算金額などを毎回更新すると、特定の領域の書き換え回数が増えてしまい、寿命を縮めてしまうから、毎回特定領域を更新するような処理は避けているのではないかと予想。
この予想が正しければ、積算処理が走るのは200, 299, 398・・・となる。
この積算処理の中で、現在利用金額を保持している領域を破壊するようなバグがあったのかも。
この手の物はリソースが少ないので、RAM領域を使いまわしてたりする事も多いため、間違えて現在利用金額を保持する領域を使ってしまったとか、PICのようにバンク切替をするようなチップでバンクの切替忘れ（切替間違い）があったか・・・
そんな感じなのではないかと。
Re:規則性 (スコア:0)
2. 溢れたら100個分追加で確保して繋げる。
3. 増やせなかったら機器の寿命という事にして有償交換させる。
4. たっだはずが99個しか追加できてない or 境界判定しくじった
って、こんな低レベルデバイスで動的確保してるとも考えづらいよなぁ..
Re:規則性 (スコア:0)
Re:規則性 (スコア:1)
> なぜそうなったのだろう…
に対して
> タレコミのリンク先に書いてあるじゃん
とツッコミが入っているように見えたのですが、単に国語力がないだけ?
Re:規則性 (スコア:1)
件のコメントは、タイトルを含めて読むと
ですよね。
rin_penguin氏の予想通りの意味にするには
でないとおかしいのでは。
Re:規則性 (スコア:1)
それこそ、タイトルを「規則性がわかった、って言ったって」本文を「規則性がどんなもんかはリリースの方に書いてあるじゃん」って書けばだいぶ五回は減ると思いますが。
タレコミと編集者のコメントを読んだ後には、大抵の人は「規則性ができた理由はたしかに気になるなあ」と思うのであって、「規則性を、リリースを読む前にタレコミ人の回りくどい表現から編集者が発見したこと」に気付く人はあまりいないでしょう。
だから、後者の「編集者に対する突っ込み」であるとは思いもよらず、前者の「規則性が生じた理由」に対するコメントとして書かれてしまうのも仕方ないと思います。
-- garmy
Re:規則性（既にオフトピ） (スコア:0)
「なら」はどっから来ました？
Re:規則性 (スコア:1)
>などと見当はずれのコメントが２つも付くというのが・・・
# これがどうして見当外れなのか俺にはさっぱりワカラネェ。
「200回以上99回毎」が謎なんじゃなくて、それ自体の理由が謎ななのさ。
200は最初からバッファ確保してるけど、次は100づつ確保したつもりで98し
か確保してないとか？リンクに2つ分使うのでここが潰されるとリンクをたど
れなくなってエラーとかかな。
Re:規則性 (スコア:1)
ソフトウェア工学的には、存在自体が謎でもあります。
何故、こんなバグが残ったまま出荷されたのか。バッファの周回処理部分はバグが出やすいから、常識的には、1回は処理を通している筈。恐らくバッファ100個で、99→100→101は正常に動作したので問題なしと判断したのではないかと思われます。つまり、かなりややこしいバグでしょう。
もし、バッファが200個あるとすると、こんな単純なことすらテストしていない体制の方が大問題です。
-- Buy It When You Found It --
Re:規則性 (スコア:1)
それも十分謎だわな。
>こんな単純なことすらテストしていない体制
いやー。案外多い気もする。
# 最近「技術者育ってねーなー」と思う製品が散見されるし。
Re:規則性 (スコア:0)
違和感があるから「見当違い」のコメントってことに
なるんでしょう。
出光クレジットのページに書いてあることをなんでわざわざ
規則性は「すぐにわかった」なんて書くんでしょうね。
と、思いながらコメントを読み始めれば、どれくらい
見当違いかわかるのでは?
Re:規則性 (スコア:1)
>規則性は「すぐにわかった」なんて書くんでしょうね。
その立場のコメントが見当違いなのはわかるのだが...
「なぜそうなったのだろう…」と繋がらなくなるからな。
# んで、後半の方が重要。
タレコミ文自体が「それ自体の理由」の方を指向してるっつー場に依
存してるからミスリードしやすいのは確かだが。
Re:規則性 (スコア:0)
だからプレスリリースに書いてあろうとなかろうと問題はないわけで、
そこを突っ込むのも分からないし、まして違和感は感じないが。
# 感じるか感じないかは主観だけど、理に反してないから突っ込むところじゃないと思うのです。
Re:規則性 (スコア:1)
それに対して，規則性はプレスリリースに書いてあるとツッコミが入った．
それを読んで，やはりプレスリリースを読んでいない第三者は，「規則性が分かった」に違和感を覚えず，ツッコミが無粋であると感じた．
と，想像．
というか，最初プレスリリースをちゃんと読んでいなかったので，まさにそう感じた．いかんですね．
Re:規則性 (スコア:0)
#誤解には違いないけど…
Re:規則性 (スコア:1)
Re:規則性 (スコア:0)
「池沼の oltio です。」
というシグネチャでもつけてくれってこったね。
Re:規則性 (スコア:0)