どこかで共有メモリの大きさが足りなかったって読んだんだけど、普通のメモリの大きさの問題だったのかな？テーブルを作るときに壊れたと書いてあるけれど読んでメモリに展開するときに上書きしたと読める部分もある。おっさんにはよくわからないのじゃ…
@popn_ja ありがとうございます！
やっぱり共有メモリへの言及は無さそうですね。どこかで共有メモリの大きさが足りなかったと読んで、共有メモリの範囲外へのアクセスはOSからシグナル（例外）をもらいそうなのにな、と思っていたのでした。
テーブルの内容への上書きがいつ起きたのかについては、いただいた記事をざっと読んだ限りでは、僕には理解できませんでした。ポンコツだなあw
@zundan 記事中に「18日の会見で分かったのは、「コピー前のテーブルのデータがすでに壊れていた」という情報だ。」と「シンプルにいえば、「ワークメモリの必要量を見誤っており、領域確保が不十分ではみ出たデータが破壊されていた」というもの。」、あと「テーブル生成プログラム」とあったので、「32bit環境ベースで作られていたテーブル生成プログラムを64bit用にリコンパイルしたら実行時に必要なワークメモリのサイズが増えたのだが、それに気づかずに実行環境へのメモリ割り当てをそのままにしていたのでぶっ壊れたテーブルを生成してしまった」と読みました。プログラムがC言語で記述されていたのも原因の１つなんですかねえ？
@popn_ja 僕は、ワークメモリの容量は定数として定義してたんだろうなあと想像してます。さっくりBUFSIZみたいなマクロを使っておいて、それぞれのテーブルはこれより小さいからこのまま行けるじゃろ、と判断したみたいな感じです。
Cでもsizeof(テーブル)+sizeof(他のテーブル)みたいに必要な領域をコンパイラに計算させればより安全かもですが、徳丸さんがTwitterで書かれていたようにアラインメントも知っておかないといけないのがつらそうです。今ならきっとメモリも潤沢にあるだろうし、それぞれのテーブルについて別々にぴったりの領域を確保しておきたくなるかもですよねー。
@zundan gihyoの画像を見るかぎり、単純にmallocした領域外に書いちゃった、と読み取りました。
環境構築時の処理とありますし、壊れたファイルを作って使っただけ、じゃないでしょうか。
> 障害の直接的な原因となった不具合を含んだロードファイル生成プログラムは、単体テストの段階では正常に動いているように見えていました。これは生成プログラムが「一時的に確保した領域」を超えて、本来ロードファイルを展開してはいけない領域（別のプログラムが利用する領域）にインデックステーブルを書き込んでしまっても、そのテストでは別のプログラムを動かしていないので上書きされることもなく、
https://gihyo.jp/article/2023/12/zengin-nttdata
とあって「テストでは別のプログラムを動かしていない」ので壊れなかったと理解すると、本番では別のプログラムを動かしていたので壊れたと読めてしまいます。ここで、ロードファイル生成プログラムを本番で全体を起動するたびに走らせてるとは僕には想像しづらいんですよねー。
あ、あと複数のプロセスが動いたから壊れたのなら、やっぱり壊れたのは共有メモリの内容じゃないといけない気もしてきました。もうﾅﾝﾓﾜｶﾗﾝw
@zundan
> 本番稼働時のロードファイル展開において作業領域が不足し、作業領域からあふれたインデックステーブルが本来ほかのプログラムが使用する領域に展開され
ともあるので、確かに壊れたのは実行時とも読めますね。
ﾅﾝﾓﾜｶﾗﾝ仲間入りします！！