こんにちは！

今日は仮想環境＋GPUなサービスにおける「Segmentation Fault」について、分析と対処法について書いてみたいと思います。

Segmentation Faultの本質と特徴

Segmentation Faultは、プログラムが保護されたメモリ領域にアクセスしようとした際にOSが発生させる例外です。
今回は複数のGPUサービス（つまりＧＰＵを使うプロセス）が動作していて、そのうちの１つを再起動したときに発生しました。
毎回発生するわけではありません。むしろ数百回の起動に1回程度ですが、1回でも発生すると絶望的な結果につながります。というのも、1つのGPUサービスの停止が SPOF となってサービス全体に影響が発生します。かつ、1回でも「Segmentation Fault」が発生してしまうと、その原因となったプロセスが二度と起動しなくなる、というやっかいな現象でした。

このように「普段は正常に動作しているのに突然動かなくなる」というのがデバッグを非常に難しくします。

とくにGPU＋仮想化の組み合わせで従来のC++アプリよりも発生確率がぐっとあがる印象があります。

まとめると以下のような感じでしょうか

• GPUを使用するサービス（画像認識、機械学習処理など）で発生頻度が高い
• 長時間の稼働後に突然発生する傾向がある
• CUDA unknown error との違いは、前者は時間を置いて再実行すると動くことがあるが、Segmentation Fault の場合、二度と起動しない。

(詳しい方ほどつっこみたくなるポイントとしてはSegmentation Fault というエラーはかなり原因がざっくりしてるので、「私たち遭遇した今回の一事例」の場合は、と読み替えていただければとおもいます）

Segmentation Fault の一般的な発生原因としては

• NULLポインタへのアクセス
• 解放済みメモリの参照
• スタックオーバーフロー
• 読み取り専用メモリへの書き込み

などがありますが、ＧＰＵ＋仮想化の環境だと、もはや何が原因だかわからないことがほとんどです。

実際の事例

さて、実際、先日、私たちが経験した事例をご紹介します。

GPUを使用するアプリケーションを実行しようとしたところ、以下のようなログが出力されました

import 'scipy.special._orthogonal' # <_frozen_importlib_external.SourceFileLoader object at 0x7fc006e862b0>
# /home/user/anaconda3/envs/image_recognition_env/lib/python3.9/site-packages/scipy/special/__pycache__/_spfun_stats.cpython-39.pyc matches ...
...
import 'yaml' # <_frozen_importlib_external.SourceFileLoader object at 0x7fc003d215e0>
...
Segmentation fault (core dumped)

●コアダンプ分析→問題の核心に迫る

GPUアプリケーション開発や運用において、特にC/C++、そしてPythonのC拡張モジュールを利用したプログラムを扱う際には、予期しないエラー「Segmentation fault」が発生することがあります。Cを特に意識しないPythonアプリでも裏でつかってるライブラリやＣＵＤＡまわりが原因で発生することもあります（最近はそれがおおいです）

このエラーは通常、「Segmentation fault (core dumped)」というメッセージと共に現れます。

ここで言う「コアダンプ（core dump）」とは一体何でしょうか？

コアダンプとは？

コアダンプとは、プログラムが異常終了した際のメモリの状態をそのままファイルとして保存したものです。これを分析することで、プログラムがどの時点で、どのような状態で停止したのかを詳細に把握でき、根本的な問題点を特定するのに役立ちます。

STEP 1: コアダンプの有効化

デフォルトではコアダンプの生成が制限されている場合があります。まず、これを解除しましょう。

# コアダンプサイズの制限を解除
ulimit -c unlimited

# コアダンプの保存場所とファイル名を指定（Ubuntu/Debianの場合）
echo '/tmp/core.%e.%p.%t' | sudo tee /proc/sys/kernel/core_pattern

これにより、クラッシュ時にコアダンプファイルが /tmp ディレクトリに、プログラム名(%e)、プロセスID(%p)、タイムスタンプ(%t)を含む名前で保存されます。

STEP 2: GDBによるコアダンプ分析

GNUデバッガ（GDB）を使って、生成されたコアダンプを分析します。

# コアダンプの分析
# 例：pythonプログラムの場合
gdb python /tmp/core.python.12345.1620000000

GDBが起動すると、プロンプトが表示されます。この中で以下のコマンドを使用して、詳しく問題点を探ります。

STEP2-1. バックトレース（スタックトレース）表示

(gdb) bt full

このコマンドでプログラムがどこで停止したかの詳細なスタックトレースが表示されます。

STEP2-2. 特定のフレームへの移動

スタックトレースから特定の関数や処理を深掘りしたいときは、フレーム番号を指定して移動します。

(gdb) frame 3

STEP 2-3. 変数の検査

特定のフレーム内での変数の値を検査できます。

(gdb) print variable_name

STEP 2-4. メモリ内容の検査

メモリアドレスに何が格納されているのかを直接調べることができます。

(gdb) x/10x memory_address

実際のエラーケースの例

よくある実際のケースとして、PythonのC拡張やGPUライブラリを使った際に、以下のようなバックトレースを得ることができます

#0  0x00007f92d3b7c7a0 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007f92d3b7e8fa in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007f92d5a1c063 in THCudaCheck () from /usr/local/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so
#3  0x00007f92d5a2e4f5 in cudaLaunchKernel () from /usr/local/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so

CUDAのカーネルが起動した際に問題が起きていることがわかります

このように外部ライブラリが関わるケースでは、ライブラリの設定やGPUドライバのバージョン不一致などが原因になることが多いですが、完全な原因の特定はほぼ不可能（時間的に）です

STEP 3: システムログの分析

コアダンプ解析だけでなく、システムレベルのログも有効な情報を提供します。以下のコマンドで関連するログをチェックしましょう。

dmesg | grep -i segfault
journalctl | grep -i segfault

これによりカーネルレベルでのメッセージが取得でき、特にメモリや仮想環境特有の問題に関する情報が得られることがあります。ですが、ここまでやってるヒマはほとんどありません。

●仮想環境特有の問題と対策

さいきんシステムはDockerやVMなど、多層でミルフィーユ状の仮想化環境が一般的になっています。
これらの環境下では、特権レベルやリソースの制限、メモリアクセスの問題がより複雑になりデバッグのやる気を確実にそいでくれます。

STEP1.DockerにおけるPtraceの問題に対処する

Dockerコンテナ内でのデバッグ作業において、ptraceシステムコールを使ったデバッガ（例えばGDBなど）を利用しようとすると、許可が無いためにエラーが発生する場合があります。
これはDockerがデフォルトでセキュリティ上の理由からSYS_PTRACEケーパビリティを無効化しているためです。

この問題を解決するためには、明示的にSYS_PTRACEを許可する必要があります。次のようなコマンドで設定できます。

# コンテナ起動時にSYS_PTRACEを有効にする
docker run --cap-add=SYS_PTRACE image_name

# すでに起動済みのコンテナにSYS_PTRACEを追加適用
docker update --cap-add=SYS_PTRACE container_name

これにより、コンテナ内で安全かつ正しくデバッガが動作できるようになります。

STEP2.pstackによるスタックトレース取得

問題発生時にプロセスがどのような状態にあるかを確認することはデバッグ作業の基本です。pstackは実行中のプロセスのスタックトレースを簡単に取得できるツールです。特に動作がフリーズしたプロセスや異常終了の原因調査に役立ちます。

pstackは次のようにして導入・利用します。

sudo apt install pstack
pstack process_id

上記のコマンドを実行すると指定したプロセスの現在のスタックトレースを即座に表示します。得られた情報から関数呼び出しの履歴を確認し、バグの発生箇所を絞り込むことができます。

STEP3.動作中プロセスの軽量診断とメモリスナップショット取得

動作中のプロセスが予期しない挙動を見せた場合、メモリの状態を含む完全なスナップショットを取ることで、後で詳細な調査が可能になります。この目的で使用されるのがgcoreです。gcoreは指定したプロセスの現在の状態をコアダンプとして保存します。

利用方法は以下の通りです。

gcore process_id  # 指定プロセスのコアダンプを生成

コアダンプが生成されると、後ほどGDBなどのデバッガを用いてその時点のプロセスメモリの内容やスタック状況を深く分析できます。これにより動作中のプロセスを停止することなく問題点の特定を進めることができます。

こんな感じで仮想環境特有のデバッグ問題は適切なツールと気合があれば比較的効果的に対処できます。とくにDockerでは特にケーパビリティの管理が重要であり、プロセス診断ツール（pstackやgcore）を併用することで根気よく問題を特定し、解決できる場合もあります。

●再発防止のためのシステム設計

さて、Segmentation Fault のような突発的で予測困難なエラーに対しては、発生自体を完全に防ぐことは難しく、エラー発生時の影響を最小化する仕組みを設けるほうが現実解といえるのではないでしょうか。

再起動とウォッチドッグプロセスの実装

「結局それかいっ！」ってなりますが、結局「再起動」がいちばん効果的なんです。

GPUを用いるサービスにおいて、プロセスが突然停止するリスクに備える最も基本的で効果的な方法は、プロセスの生存を監視し、停止した場合に自動的に再起動を試みるウォッチドッグの実装してみましょう。

以下に、Pythonを用いたシンプルなウォッチドッグのシンプルな実装例を示します。

import subprocess
import time
import logging

def run_with_watchdog(command, max_retries=3, wait_time=5):
    for attempt in range(max_retries):
        try:
            process = subprocess.Popen(command, shell=True)
            return_code = process.wait()
            if return_code == 0:
                return True
            logging.warning(f"プロセスが終了コード {return_code} で終了しました。再試行 {attempt + 1}/{max_retries}")
        except Exception as e:
            logging.error(f"例外が発生しました: {e}. 再試行 {attempt + 1}/{max_retries}")
        time.sleep(wait_time)
    return False

# 使用例
run_with_watchdog("CUDA_VISIBLE_DEVICES=1 python image_recognition_server.py")

このようなウォッチドッグは特にサービス運用中に役立ち、Segmentation Fault による一時的な停止をリカバリーできます

systemdを利用したサービス監視

Linux環境では、より堅牢で標準的なプロセス管理方法として、systemdを利用したサービス自動再起動の仕組みが推奨です

以下にsystemdの設定例を示します。

# /etc/systemd/system/image-recognition.service
[Unit]
Description=Image Recognition Service
After=network.target

[Service]
User=app_user
WorkingDirectory=/opt/app
ExecStart=/usr/bin/python3 /opt/app/image_recognition_server.py
Restart=on-failure
RestartSec=5s
Environment="CUDA_VISIBLE_DEVICES=0"
Environment="PYTHONPATH=/opt/app"

[Install]
WantedBy=multi-user.target

systemdを用いることで、プロセスが異常終了した際に自動的に再起動され、サービスの可用性がキープできますね

GPUおよびプロセスメモリ使用状況の把握

GPUおよびプロセスのメモリ使用状況をモニタリングすることで、メモリの断片化やリソースの枯渇を早期に察知できます。

# GPUメモリ状況の確認
nvidia-smi

# プロセスのメモリマップ確認
cat /proc/<PID>/maps

メモリエラー検出ツールの活用

# AddressSanitizer（メモリリーク・オーバーフロー検出）
PYTHONMALLOC=malloc ASAN_OPTIONS=detect_leaks=0 python -m pip install --no-binary :all: problematic_package

# Valgrindによるメモリリーク詳細調査
valgrind --leak-check=full python script.py

# 実行中プロセスのスタックトレース取得
pstack process_id

●実践的な解決案

さんざん書いてきましたが、結局、再起動が最強です。

再起動といっても、段階的なアプローチを使いましょう

STEP1. 環境変数の微調整による再実行

CUDA_VISIBLE_DEVICES=1 python script.py
CUDA_VISIBLE_DEVICES=0 PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:128 python script.py

STEP2. 仮想環境またはコンテナの再起動

Dockerの場合:

docker restart container_name

WSLの場合:

wsl --shutdown

STEP3. ホストシステム全体の再起動

Linux:

sudo reboot

Windows:

再起動を選択

このように段階的に再起動を試します。
GPU+仮想環境＋Segmentation Fault のときに経験的にもっとバランスがいいのが STEP2 のコンテナ・仮想環境の再起動です。今回の事例のように、複数のプロセスが１つのＧＰＵのメモリを共有しているとき、１つのプロセスがSegmentation Fault になったとき、そのプロセスを再起動しても復旧しないことが多いです。おそらく複数のプロセスによる複雑なメモリの断片化などがＧＰＵ内で起こっているためだとおもわまれう。このとき、コンテナ・仮想環境の再起動をすることで、ＧＰＵメモリを食っているプロセスをいったんすべて引きはがすことができるからです。ＯＳ再起動に比べ、比較的高速にサービスを復旧できる点も魅力的です。

●定期メンテナンスによる再発防止

さて、突発的な問題の発生を防ぐには、そもそも定期的な再起動やメンテナンス計画を組むこともがそもそも基本ですね。

まとめ

さて今回は Segmentation Fault からはじめて、
その原因、分析方法、発生してしまったときの対処方法、予防についてざざっとかいてみました。Segmentation Faultの対応では、根本原因を完全に突き止めることは難しい場合がありますが、分析と予防の両面から階層的なアプローチを組み合わせることで、高い実用性とシステムの可用性をキープできるよう、引き続き取り組んでいきたいとおもいます。今回も「結局、再起動かーい」になってしまいましたが、エンジニアリングの本質は、複雑な問題に対してシンプルで堅牢な解決策を選ぶことだとおもっており、適切な監視、自動化、定期的なメンテナンスを組み合わせて問題の影響を最小化できるよう努力していきたいとおもいます。

関連記事

本番運用におけるPyTorch+CUDAサーバーでの「Unknown Error」問題とその対策
https://blog.qualiteg.com/how_to_address_cuda_unknown_error/