どこかで共有メモリの大きさが足りなかったって読んだんだけど、普通のメモリの大きさの問題だったのかな?テーブルを作るときに壊れたと書いてあるけれど読んでメモリに展開するときに上書きしたと読める部分もある。おっさんにはよくわからないのじゃ…
Conversation
Notices
-
Embed this notice
zunda (zundan@mastodon.zunda.ninja)'s status on Wednesday, 06-Dec-2023 13:49:48 JST zunda -
Embed this notice
zunda (zundan@mastodon.zunda.ninja)'s status on Wednesday, 06-Dec-2023 14:25:49 JST zunda @popn_ja ありがとうございます!
やっぱり共有メモリへの言及は無さそうですね。どこかで共有メモリの大きさが足りなかったと読んで、共有メモリの範囲外へのアクセスはOSからシグナル(例外)をもらいそうなのにな、と思っていたのでした。
テーブルの内容への上書きがいつ起きたのかについては、いただいた記事をざっと読んだ限りでは、僕には理解できませんでした。ポンコツだなあw
-
Embed this notice
ぽぷんじゃ (popn_ja@omoro.info)'s status on Wednesday, 06-Dec-2023 14:25:50 JST ぽぷんじゃ @zundan 全銀の障害原因についてはこの記事を読んだよ
https://www.watch.impress.co.jp/docs/series/suzukij/1551556.html
-
Embed this notice
zunda (zundan@mastodon.zunda.ninja)'s status on Wednesday, 06-Dec-2023 14:51:22 JST zunda @popn_ja 僕は、ワークメモリの容量は定数として定義してたんだろうなあと想像してます。さっくりBUFSIZみたいなマクロを使っておいて、それぞれのテーブルはこれより小さいからこのまま行けるじゃろ、と判断したみたいな感じです。
Cでもsizeof(テーブル)+sizeof(他のテーブル)みたいに必要な領域をコンパイラに計算させればより安全かもですが、徳丸さんがTwitterで書かれていたようにアラインメントも知っておかないといけないのがつらそうです。今ならきっとメモリも潤沢にあるだろうし、それぞれのテーブルについて別々にぴったりの領域を確保しておきたくなるかもですよねー。
-
Embed this notice
ぽぷんじゃ (popn_ja@omoro.info)'s status on Wednesday, 06-Dec-2023 14:51:23 JST ぽぷんじゃ @zundan 記事中に「18日の会見で分かったのは、「コピー前のテーブルのデータがすでに壊れていた」という情報だ。」と「シンプルにいえば、「ワークメモリの必要量を見誤っており、領域確保が不十分ではみ出たデータが破壊されていた」というもの。」、あと「テーブル生成プログラム」とあったので、「32bit環境ベースで作られていたテーブル生成プログラムを64bit用にリコンパイルしたら実行時に必要なワークメモリのサイズが増えたのだが、それに気づかずに実行環境へのメモリ割り当てをそのままにしていたのでぶっ壊れたテーブルを生成してしまった」と読みました。プログラムがC言語で記述されていたのも原因の1つなんですかねえ?
-
Embed this notice