アカウント名:
パスワード:
板情報を配信するプログラムは本来、1銘柄当たり1280バイトの作業用メモリー領域を2万8000銘柄分、合計3万5000Kバイト確保するよう記述しなければならない。だが、1銘柄当たりのメモリー領域を誤って4バイトとしてしまったため、プログラムは本来の320分の1の109.375Kバイトしか確保しなかった。結果として89銘柄以上の板情報の問い合わせが同時に発生すると、作業用メモリーが足りなくなり、情報配信システムがダウンした。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
ちょっと違う (スコア:4, 参考になる)
データ容量のサイズが28000銘柄分のはずが88銘柄分しか確保できてなかった。
http://itpro.nikkeibp.co.jp/article/NEWS/20080722/311271/
Re: (スコア:5, 参考になる)
Re: (スコア:1)
Re: (スコア:1, 興味深い)
皆さん現役の方ですよね。世の中にはこの手のバグを飼ってるソフトが多数出荷されてるってことになりますか。
Re:ちょっと違う (スコア:0)
だが、富士通から納入されている売買システムはＣＯＢＯＬだから今回の先物システムもＣＯＢＯＬじゃないの？
ＣＯＢＯＬでヌルポやポインタ記述ミスは起こらない。
そこで他の方が書かれているようにストレステストじゃなくてエラー処理検証用に最大数を８８（適当な数字）にして
エラーシーケンスのテスト後戻し忘れじゃないの？
これは受け入れ検査時だと思うので東証側のシステム担当者が悪い？ 保身の為にメーカに責任を負わせると次のシステムも
富士通に決定。
原因不明と言うよりも、”ヌルポ！ ガッ！”って言っとくほうが恥ずかしいバグですが誰もが納得して修正後は根治されたと納得できる。