GPUサービスで「Segmentation Fault 」に出会ったら~分析から解決までの実践アプローチ~

GPUサービスで「Segmentation Fault 」に出会ったら~分析から解決までの実践アプローチ~

こんにちは!

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

Segmentation Faultの本質と特徴

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

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

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

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

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

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

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

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

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

実際の事例

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

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アプリでも裏でつかってるライブラリやCUDAまわりが原因で発生することもあります(最近はそれがおおいです)

このエラーは通常、「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 のコンテナ・仮想環境の再起動です。今回の事例のように、複数のプロセスが1つのGPUのメモリを共有しているとき、1つのプロセスがSegmentation Fault になったとき、そのプロセスを再起動しても復旧しないことが多いです。おそらく複数のプロセスによる複雑なメモリの断片化などがGPU内で起こっているためだとおもわまれう。このとき、コンテナ・仮想環境の再起動をすることで、GPUメモリを食っているプロセスをいったんすべて引きはがすことができるからです。OS再起動に比べ、比較的高速にサービスを復旧できる点も魅力的です。

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

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

まとめ

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

関連記事

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

Read more

AIがよく間違える「クロージャ問題」の本質と対策

AIがよく間違える「クロージャ問題」の本質と対策

こんにちは! 本日は「クロージャ問題」に関する話題となります。 Pythonでループ内に関数を定義したことはありますか? もしあるなら、あれれ?な挙動に遭遇したことがあるかもしれません。 本稿では、Pythonプログラマーなら一度は経験する「クロージャ問題」について、初心者にもわかりやすく解説してみたいとおもいます クロージャとは何か? そもそも ”クロージャ” とは何でしょうか。 クロージャ(closure)とは、関数が自分の定義されたスコープの変数を覚えて持ち運ぶ仕組み のことです。 もう少し分解すると、次の2つがポイントとなります 1. 内側の関数が、外側の関数の変数を使える 2. 外側の関数が終了しても、その変数は生き続ける 普通の関数とクロージャ―を使った関数を比較してみましょう 普通の関数との比較 まずは普通の関数から、 def add(x, y): return x + y print(add(3, 5)) # 8 print(add(3, 7)

By Qualiteg プロダクト開発部
フリーランスHub様にQualiteg Blogをご紹介いただきました

フリーランスHub様にQualiteg Blogをご紹介いただきました

この度、フリーランス向け案件検索サービス「フリーランスHub」様の特集記事「トレンドをキャッチアップ!AIに関する情報が得られるメディア・ブログまとめ」にて、弊社が運営する「Qualiteg Blog」をご紹介いただきました。 掲載記事について フリーランスHub様の記事では、AI技術の最前線で活躍するエンジニアや開発者の方々に向けて、価値ある情報源となるメディア・ブログが厳選して紹介されています。 その中で、Qualiteg Blogを「AI技術の専門知識を実践的なビジネス活用につなげる貴重な情報源」として取り上げていただきました。 特に以下の点を評価いただいております * 実践的なビジネス活用事例の提供 AI新規事業創出や事業選定方法など、経営者やビジネスリーダーが直面する課題への具体的な解決策 * 技術的な深掘りコンテンツ リップシンク技術など、実際のサービスで使用されている技術の開発現場目線での詳細な解説 * 多様な情報発信 代表執筆記事、AIトピックス、講演会動画など、幅広いフォーマットでの情報提供 今後も価値ある情報発

By Qualiteg ニュース
PyTorchの重いCUDA処理を非同期化したらメモリリークした話と、その解決策

PyTorchの重いCUDA処理を非同期化したらメモリリークした話と、その解決策

こんにちは!Qualitegプロダクト開発部です! 今回は同期メソッドを非同期メソッド(async)化しただけなのに、思わぬメモリリーク※に見舞われたお話です。 深層学習モデルを使った動画処理システムを開発していた時のことです。 「処理の進捗をリアルタイムでWebSocketで通知したい」という要件があり、「単にasync/awaitを使えばいいだけでしょ?」と軽く考えていたら、思わぬ落とし穴にはまりました。 プロ仕様のGPUを使っていたにも関わらず、メモリ不足でクラッシュしてしまいました。 この記事では、その原因と解決策、そして学んだ教訓を詳しく共有したいと思います。同じような問題に直面している方の参考になれば幸いです。 ※ 厳密には「メモリリーク」ではなく「メモリの解放遅延」ですが、 実用上の影響は同じなので、この記事では便宜上「メモリリーク」と表現します。 背景:なぜ進捗通知は非同期である必要があるのか モダンなWebアプリケーションの要求 最近のWebアプリケーション開発では、ユーザー体験を向上させるため、長時間かかる処理の進捗をリアルタイムで表示することが

By Qualiteg プロダクト開発部
ゼロトラスト時代のLLMセキュリティ完全ガイド:ガーディアンエージェントへの進化を見据えて

ゼロトラスト時代のLLMセキュリティ完全ガイド:ガーディアンエージェントへの進化を見据えて

こんにちは! 今日はセキュリティの新たな考え方「ゼロトラスト」とLLMを中心としたAIセキュリティについて解説いたします! はじめに 3つのパラダイムシフトが同時に起きている いま、企業のIT環境では3つの大きな変革が起ころうとしています。 1つ目は「境界防御からゼロトラストへ」というセキュリティモデルの転換。 2つ目は「LLMの爆発的普及」による新たなリスクの出現。 そして3つ目は「AIエージェント時代の到来」とそれに伴う「ガーディアンエージェント」という新概念の登場です。 これらは別々の出来事のように見えて、実は密接に関連しています。本記事では、この3つの変革がどのように結びつき、企業がどのような対策を取るべきかを解説いたします 目次 1. はじめに:3つのパラダイムシフトが同時に起きている 2. 第1の変革:ゼロトラストという新しいセキュリティ思想 3. 第2の変革:LLM時代の到来とその影響 4. 第3の変革:AIエージェントとガーディアンエージェント 5. 3つの変革を統合する:実践的なアプローチ 6. 実装のベストプラクティス 7. 日本

By Qualiteg コンサルティング