C++ AddressSanitizerの使い方：メモリバグを早期発見するための設定と活用法

2026年5月1日

デバッグ

C++によるソフトウェア開発において、最も困難で時間を浪費する作業の一つがメモリ関連のバグ修正です。

バッファオーバーフローやメモリリーク、解放済みメモリへのアクセスといった問題は、実行時にクラッシュを引き起こすだけでなく、時には再現性の低い「謎の挙動」として開発者を悩ませます。

こうした課題を解決するための強力な武器が、Googleによって開発され、現在は主要なコンパイラに統合されているAddressSanitizer (ASan)です。

本記事では、AddressSanitizerの基本的な使い方から、実務で役立つ詳細な設定、そして最新のC++開発環境における活用法までを詳しく解説します。

目次 [ close ]

AddressSanitizerとは

AddressSanitizer (以下 ASan) は、C++やC言語向けの高速なメモリ誤用検知ツールです。

コンパイル時にプログラムに検査用のコードを挿入 (インストルメンテーション) することで、実行時のメモリ操作を監視し、不正なアクセスを瞬時に検出します。

かつてメモリバグの調査には Valgrind などのエミュレーションベースのツールが使われてきましたが、ASan はそれらに比べて圧倒的に動作が高速であるという特徴があります。

通常、Valgrind では実行速度が10倍から50倍ほど低下しますが、ASan によるオーバーヘッドは概ね2倍程度に抑えられます。

このパフォーマンスの高さにより、開発中のデバッグ時だけでなく、ユニットテストや CI (継続的インテグレーション) 環境でも常用することが可能になっています。

ASanが検出できる主なエラー

ASan は、プログラムがメモリアドレスを不適切に扱う以下のパターンを網羅的に検出します。

Heap buffer overflow：ヒープ領域に確保した配列の範囲外アクセス
Stack buffer overflow：スタック領域にあるローカル変数の範囲外アクセス
Global buffer overflow：グローバル変数の範囲外アクセス
Use after free (Dangling pointer)：解放済みのメモリ領域へのアクセス
Use after return：関数終了後に消滅したスタック変数へのアクセス
Double free / Invalid free：二重解放や不適切なポインタの解放
Memory leaks：解放し忘れたメモリの検出 (LeakSanitizer)

各コンパイラでのセットアップ方法

現代の主要なコンパイラである GCC、Clang、および Microsoft Visual C++ (MSVC) はすべて ASan をサポートしています。

GCC / Clang での使用方法

Linux や macOS 環境で GCC または Clang を使用している場合、コンパイル時とリンク時の両方のオプションに -fsanitize=address を追加するだけで有効になります。

Shell

# コンパイルとリンクを同時に行う例
g++ -O1 -g -fsanitize=address main.cpp -o app

# 分割コンパイルを行う場合
g++ -c -O1 -g -fsanitize=address main.cpp
g++ -fsanitize=address main.o -o app

デバッグ情報を付与するために -g オプションを、また、エラー発生時のスタックトレースを分かりやすくするために最低限の最適化 -O1 以上を適用することが推奨されます。

Visual Studio (MSVC) での使用方法

Windows 環境の Visual Studio 2019 バージョン 16.9 以降でも ASan が正式にサポートされています。

プロジェクトのプロパティを開きます。
「構成プロパティ」 > 「C/C++」 > 「全般」を選択します。
「AddressSanitizer を有効にする」 を「はい (/fsanitize=address)」に変更します。

また、実行時には適切なランタイムライブラリが必要になるため、環境変数 PATH に MSVC の ASan DLL が含まれていることを確認してください。

AddressSanitizerの基本的な活用例

具体的なコードを用いて、ASan がどのようにエラーを報告するのかを見ていきましょう。

1. ヒープバッファオーバーフローの検出

以下のコードは、動的に確保した配列の範囲外にアクセスしようとする典型的なバグを含んでいます。

C++

#include <iostream>
#include <vector>

int main() {
    // 10要素の配列を確保
    int* array = new int[10];

    // 意図的に11番目の要素(インデックス10)にアクセス
    array[10] = 42; 

    std::cout << "Value: " << array[10] << std::endl;

    delete[] array;
    return 0;
}

このコードを ASan 有効化状態で実行すると、以下のようなエラーレポートが出力されます。

text

==12345==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x604000000038 at pc 0x55ef4321...
WRITE of size 4 at 0x604000000038 thread T0
    #0 0x55ef4321 in main main.cpp:9
    #1 0x7f923456 in __libc_start_main...
...
0x604000000038 is located 0 bytes to the right of 40-byte region [0x604000000010,0x604000000038)
allocated by thread T0 here:
    #0 0x7f927890 in operator new[](unsigned long)...
    #1 0x55ef4321 in main main.cpp:6

レポートには、どのファイルの何行目で不正な書き込みが行われたか、およびそのメモリがどこで確保されたものかが明確に示されます。

2. Use After Free (解放後使用) の検出

一度 delete したメモリを再利用してしまうバグは、非常に深刻な脆弱性につながります。

C++

#include <iostream>

int main() {
    int* p = new int(100);
    delete p; // メモリを解放

    // 解放済みのメモリにアクセス
    std::cout << "Dereferencing p: " << *p << std::endl; 

    return 0;
}

このプログラムを実行すると、ASan は heap-use-after-free を報告します。

ASan はメモリを解放した直後、その領域を「隔離 (Quarantine)」状態にし、即座に再利用されないように制御することで、この種のミスを確実に捉えます。

高度な診断を可能にする設定：ASAN_OPTIONS

ASan の動作は、環境変数 ASAN_OPTIONS を設定することで細かくカスタマイズできます。

これにより、デフォルトでは無効になっている機能の有効化や、出力形式の変更が可能です。

主要なオプション一覧

オプション名	説明	推奨値
`detect_leaks`	メモリリークを検出するかどうか。	`1`
`log_path`	ログをファイルに出力する場合のパスを指定。	(任意)
`abort_on_error`	エラー検出時に `abort()` を呼び出す。	`1`
`detect_stack_use_after_return`	関数の戻り値後のスタック使用を検出。	`1`
`color`	出力ログのカラー表示設定。	`always`

設定例

Linux 環境で、詳細なスタックトレースを取得しつつメモリリークもチェックする場合は、以下のように実行します。

Shell

export ASAN_OPTIONS="detect_leaks=1:detect_stack_use_after_return=1:check_initialization_order=1"
./app

Windows の場合は、コマンドプロンプトや PowerShell で環境変数をセットします。

PowerShell

$env:ASAN_OPTIONS="detect_leaks=1"
.\app.exe

メモリリークの検出 (LeakSanitizer)

ASan には LeakSanitizer (LSan) が統合されており、プログラム終了時に解放されていないメモリを一覧表示します。

C++

void createLeak() {
    int* leak = new int[100];
    // delete[] leak; を忘れている
}

int main() {
    createLeak();
    return 0;
}

このコードを実行すると、終了時に以下のレポートが表示されます。

text

=================================================================
==12345==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 400 byte(s) in 1 object(s) allocated from:
    #0 0x7f927890 in operator new[](unsigned long)...
    #1 0x55ef4321 in createLeak() main.cpp:2
    #2 0x55ef4321 in main main.cpp:7

「どこで確保されたメモリが漏れているのか」を直接示してくれるため、従来のデバッグ手法よりも遥かに効率的にリーク箇所を特定できます。

実践的な運用と注意点

ASan は非常に強力ですが、導入にあたっていくつか考慮すべきポイントがあります。

1. パフォーマンスへの影響

ASan は高速ですが、それでも CPU 速度は約 2 倍、メモリ消費量は 2 倍から 4 倍程度に増加します。

これは、ASan がメモリの各バイトの状態を管理するために「シャドウメモリ (Shadow Memory)」という領域を確保するためです。

リソースが極端に制限された組み込み環境や、リアルタイム性が厳格に求められる処理では、ASan を有効にしたまま運用するのは難しい場合があります。

2. ライブラリの互換性

プログラム全体を ASan でチェックするためには、依存しているライブラリも ASan を有効にしてコンパイルされていることが理想的です。

ASan を有効にしたコードと、無効な状態でビルドされた外部ライブラリを混ぜてリンクすることも可能ですが、ライブラリ内部で発生したメモリバグを見落としたり、稀に偽陽性 (False Positive) が発生したりすることがあります。

3. 未定義動作すべてを網羅するわけではない

ASan は主に「メモリアドレス」に関する問題を扱います。

論理的なバグや、初期化されていない変数の使用 (これは MemorySanitizer の範疇)、スレッド間のデータレース (これは ThreadSanitizer の範疇) をすべて単独でカバーするわけではありません。

目的のバグに応じて、他の Sanitizer ツールと使い分けることが重要です。

CI/CD への組み込み

モダンな開発プロセスでは、ASan を CI (継続的インテグレーション) パイプラインに組み込むことが推奨されます。

GitHub Actions や GitLab CI などの環境で、ユニットテストを実行する際に ASan を有効化することで、マージ前のコードにメモリバグが混入するのを自動的に防ぐことができます。

例えば、GitHub Actions のワークフローファイルでは以下のように設定します。

YAML

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build with ASan
        run: g++ -fsanitize=address -g test.cpp -o test_runner
      - name: Run Tests
        run: ./test_runner

ASan はエラーを検出するとゼロ以外の終了コードを返すため、テストが失敗としてマークされ、開発者は即座に異常に気づくことができます。

まとめ

AddressSanitizer は、C++開発者にとって「必須」と言っても過言ではないほど強力なツールです。

かつては複雑な設定が必要だったメモリデバッグも、今やコンパイルオプションを一つ追加するだけで、プロフェッショナルなレベルの解析が可能になりました。

早期発見：開発の初期段階で導入することで、バグが複雑化する前に修正できます。
高い信頼性：誤検知が非常に少なく、報告された内容はほぼ確実に修正が必要な箇所です。
運用の容易さ：GCC/Clang/MSVC すべてで利用可能であり、既存のプロジェクトにも導入しやすい。

メモリバグは、時に製品の信頼性を根底から揺るがし、セキュリティ上の脆弱性となります。

AddressSanitizer を日々の開発ルーチンに取り入れ、より安全で高品質な C++ プログラムの構築を目指しましょう。