コグノスケ

Debian TestingとZephyr SDKその1 - 自分でSDKをビルド

目次: Zephyr

開発用のマシンではDebian Testingを使っているのですが、久しぶりにdist-upgradeしたところPython 3.8が消えてしまいました。Python 3.9に移行したみたいです。

アップデート時は「そうなんだ、3.9になったんだな。」くらいの認識でスルーしまいたが、Zephyrを使おうとしたら異変に気づきました。なんとZephyr SDKのGDBが動きません。どうしてこうなった。

$ riscv64-zephyr-elf-gdb
riscv64-zephyr-elf-gdb: error while loading shared libraries: libpython3.8.so.1.0: cannot open shared object file: No such file or directory

Debianは元々Zephyr SDKのサポート範囲に入っていない（Ubuntuのみ）ですし、Debian Testingなんてサポートされるはずがないので、自力で解決する必要があります。

Zephyr SDKのビルド

Zephyr SDKのビルド手順は簡単ですが、Debian Testingだとうまくいきません。

$ git clone https://github.com/zephyrproject-rtos/sdk-ng
$ cd sdk-ng

$ ./go.sh riscv64
./go.sh: 行17: python: コマンドが見つかりません

Pythonが見つからず怒られます。Debian Testingは /usr/bin/pythonがなくなったため、go.shのpythonをpython3に書き換えてあげると動きます。他にもPython 3.8を想定している箇所があるので、Python 3.9に直します。

diff --git a/configs/riscv64.config b/configs/riscv64.config
index 295f2c0..a9fc301 100644
--- a/configs/riscv64.config
+++ b/configs/riscv64.config
@@ -46,5 +46,5 @@ CT_CC_LANG_CXX=y
 CT_CC_GCC_LIBSTDCXX_NANO=y
 CT_DEBUG_GDB=y
 CT_GDB_V_9_2=y
-CT_GDB_CROSS_PYTHON_BINARY="python3.8"
+CT_GDB_CROSS_PYTHON_BINARY="python3.9"
 CT_GDB_CROSS_BUILD_NO_PYTHON=y
diff --git a/go.sh b/go.sh
index e5442fa..7a45fd8 100755
--- a/go.sh
+++ b/go.sh
@@ -14,7 +14,7 @@ fi
 
 COMMIT="d7da3a9c7f0f3a90bb4c71b91aea6cbc2471a541"
 GITDIR=${PWD}
-JOBS=$(python -c 'import multiprocessing as mp; print(mp.cpu_count())')
+JOBS=$(python3 -c 'import multiprocessing as mp; print(mp.cpu_count())')
 
 unameOut="$(uname -s)"
 unameMachine="$(uname -m)"

SDKはbuild/output以下に生成されます。RISC-V 64であればbuild/output/riscv64-zephyr-elfです。生成されたバイナリが動くか確かめましょう。

$ cd build/output/riscv64-zephyr-elf/bin

$ ./riscv64-zephyr-elf-gdb
Segmentation fault

SEGVで死にました。うーん、だめそうですね……。次回以降、直せないかトライします。

Windowsの仮想メモリサイズの謎

目次: Windows

Windowsで「コミット済み」（＝仮想メモリの合計）の値を求める方法がさっぱりわかりません。タスクマネージャーの「パフォーマンス」タブには下記のように値が表示されています。

タスクマネージャー「コミット済み」の例

しかしタスクマネージャーの「詳細」タブに表示される、各プロセスのコミットサイズ（＝仮想メモリサイズのことらしい）を足しても全く足りません。どういうこと？？

タスクマネージャー「コミットサイズ」の例

コミットサイズが全然信用できない例を挙げれば、AMDのRadeonドライバ関連でAMDRSServ.exeというプロセスがいます。このプロセスをタスクマネージャーで見ると「5MBしか使ってないよ」とおっしゃっています。

AMDRSServ.exeのコミットサイズは5MB

ところがプロセスを強制終了させると、突然700MBほど（6.2GB → 5.5GB）仮想メモリが解放されます。700MBも使っているプロセスはありませんでしたが、700MBどこから来た？意味不明ですね。

AMDRSServ.exe強制終了前

AMDRSServ.exe強制終了後

たぶんカーネル側というかドライバ内で仮想メモリをでかく取ると「コミット済み」と「各プロセスのコミットサイズの合計」の乖離が激しくなるんじゃないか？と予想していますが、調べ方がわかりません。

Windowsを使っていて仮想メモリが枯渇するような事態に陥り、調べる必要が出てきたとしても、タスクマネージャーの表示してる「コミットサイズ」は全然信用できないってことです。ひどい作りだなあ、もう。

WindowsとLinuxのメモリ割り当て戦略の違い

目次: Linux
目次: Windows

新年早々、WindowsとLinuxのメモリ割り当て戦略の基本的な違いをすっかり忘れていて、ひどい目に合いました。

症状としてはSteamでゲームをしてると頻繁にゲームが落ちたり、ブラウザがクラッシュします。

何を調べた？

疑った順に、

AMDのグラフィクスドライバ？

• バージョンアップしてもダメ。
• クロックダウンしてもダメ。
• 無効化し（Intel内蔵グラフィクスに切り替え）てもダメ。

熱暴走？

• Intel内蔵グラフィクス切り替え＋CPUクロックダウンで熱を抑えて、50℃行ってないのにダメ。

メモリ不足？

• 物理メモリは数GB余っているのにダメ。

結論は？

仮想メモリの枯渇でした。Windowsは仮想メモリを物理メモリ＋ページングファイルの合計量までしか割り当てません。私の環境は物理メモリ16GB＋ページングファイル1GBに切り詰めていたため、仮想メモリは17GBまでしか確保できません。

ゲーム＋ブラウザを起動すると仮想メモリの消費量が17GBを超えるときがあります。仮想メモリの割り当て量が上限ギリギリに達して、ゲームもしくはブラウザの運が悪い方が、仮想メモリを要求すると、割り当てに失敗します。

するとNULLポインタが返り、NULLポインタにアクセスしてゲームorブラウザがクラッシュしてしまうようです。誰一人として、仮想メモリの割り当て失敗を想定せんの？誰か1人くらいVirtualAlloc() が失敗したって教えてくれても良いのに……。

対策は？

ページングファイルを適当に増やせば（とりあえず16GBくらいにした）安定しました。

なぜそう判断した？

気づいたきっかけはゲーム（Cities: Skylines）のクラッシュダンプです。

クラッシュダンプのエラーログ

エラーログを見るとpaging fileの空きが1MBしかありません。Windowsではこれは仮想メモリの空きを表すそうです。これを知らなかったがために、全然関係ないドライバとか熱暴走を疑い、遠回りしてしまいました。

確認方法は？

タスクマネージャーで「コミット済み」の値をチェックすると、仮想メモリの使用量がわかります。これがゲーム＋ブラウザで17GBを超えていました。

タスクマネージャー「コミット済み」の例

ダメ押しで、下記のようなVirtualAlloc() APIを呼んで仮想アドレスを大量にガメる（物理メモリはほぼ消費しない）プログラムを書いて、わざと仮想メモリだけを枯渇させました。

#include <cstdio>
#include <cstdlib>
#include <windows.h>

#define CNT    16

int main()
{
	const size_t s = 1024 * 1024 * 1024;
	char buf[1024], *pb;
	void *p[CNT];

	for (int c = 0; c < CNT; c++) {
		p[c] = VirtualAlloc(NULL, s, MEM_COMMIT, PAGE_READWRITE);

		FormatMessageA(FORMAT_MESSAGE_FROM_SYSTEM, NULL, GetLastError(), 0, buf, sizeof(buf) - 1, NULL);
		printf("%s\n", buf);

		pb = (char*)p[c];
		for (size_t i = 0; i < s / 8192; i++)
			pb[i] = (char)i;
	}

	for (int c = 0; c < CNT; c++)
		VirtualFree(p[c], s, MEM_DECOMMIT);

	return 0;
}

この状態でゲームを動かすと容易に同じクラッシュが起こせます。というわけで仮想メモリの枯渇で確定と判断しました。

反省点は？

WindowsとLinuxの仮想メモリ割り当て戦略は全く違うのに、同じノリでWindowsのページングファイルを削ってしまったことですね……。一応、違いは知っていたんですが、行動に活かせず思い切りハマりました。

補足

Windowsは仮想メモリ割当てが保守的です。仮想メモリの割り当て上限＝物理メモリ＋ページファイルの合計となります。

• 利点: 全プロセスが仮想メモリ全域にアクセスしても、物理メモリ＋スワップで対応できます。仮想メモリと物理メモリの対応は必ずできて、プロセスをKillする必要は原理的に発生しません。
• 欠点: 仮想メモリを確保だけしてアクセスしないプロセスが大量にいると、仮想メモリが先に枯渇します。物理メモリは遊んだままで無駄になります。

Linuxは仮想メモリの割り当て上限＞物理メモリ＋スワップファイルの合計となります（over commitment）。

• 利点: 仮想メモリを無駄に確保するやつがいても、物理メモリ＋スワップを使い切れます。
• 欠点: 全プロセスが仮想メモリにアクセスしてしまうと、仮想メモリに紐づける物理メモリorスワップ領域が不足し、メモリ使用量を減らすためプロセスをKillせざるを得なくなります。

WindowsとLinuxのメモリ割り当て戦略は、利点と欠点が逆になるだけで、どっちもどっちです。

まとめ

今回の教訓をおさらいすると、Windowsを使っているのに、Linuxと同じノリでページファイルを1GBとか小さいサイズに削ると、速攻で仮想メモリが枯渇してひどい目に合うんでやめようね！ってことです。