【テクニカル・上級編】未定義動作（UB）を徹底駆逐！UBSan（UndefinedBehaviorSanitizer）による実行時監視の現場 – 実行環境・ランタイム・コンパイラ生産性向上バイブル

未定義動作（UB）という時限爆弾を制圧せよ：UBSanによる実行時監視の極限最適化

開発現場において、C/C++言語における「未定義動作（Undefined Behavior: UB）」ほど厄介な存在はない。
静的解析ツールがどれほど進化しようとも、コンパイラがどれほど賢くなろうとも、ポインタの不正算術、符号付き整数のオーバーフロー、シフト演算のオーバーフロー、ヌルポインタのデリファレンスといった論理的バグの多くは、静的コード片の解析だけではすり抜ける。

AddressSanitizer (ASan) がヒープの領域外アクセスやuse-after-freeといった「空間的・時間的なメモリ破壊」を暴くのに対し、UndefinedBehaviorSanitizer (UBSan) は、「C言語仕様のグレーゾーン、あるいは完全に踏み抜いてはならない禁忌」を、実行時のコードインストゥルメンテーションによってリアルタイムに検知する。

本稿では、単なるコンパイルフラグの紹介に留まらない。プロダクション環境を模したコンテナでの完全自動化、CI/CDパイプラインへのシームレスな統合、そしてオーバーヘッドを極限まで削ぎ落とすためのアーキテクチャハックを、伝説的DevOpsアーキテクトの視点から完全解説する。

—

1. UBSanの内部メカニズムとオーバーヘッドの真実

なぜUBSanは未定義動作を検知できるのか。その本質は、コンパイラによるコードの強制的な書き換え（インストゥルメンテーション）にある。

コンパイル時インジェクションの挙動

UBSanを有効にしてビルドを行うと、Clang/GCCは例えば以下のような単純な加算演算に対しても、バックグラウンドで厳密なチェックコードを挿入する。

// 開発者が書いたコード
int c = a + b;

これがコンパイル時（`-fsanitize=signed-integer-overflow` 有効時）に、内部で次のようなアサーション付きの安全な処理へと変換される。

// UBSanが背後で挿入する論理的同等コード
int c;
if (__builtin_add_overflow(a, b, &c)) {
__ubsan_handle_add_overflow(…); // エラーレポートを出力してアボート
}

パフォーマンスへの影響と実務的なトレードオフ

このインストゥルメンテーションは強力無比であるが、代償としてCPUサイクルを消費する。一般的に、UBSanをフル有効化したバイナリは、5%から20%程度のパフォーマンス低下、およびバイナリサイズの肥大化（約10〜30%）を引き起こす。

だからこそ、「本番環境（Production）で常時稼働させるべきではない」。
我々が目指すべきDevOpsアーキテクチャは、「CI/CDのテストフェーズおよび夜間統合テスト環境（Staging）においてのみ、完全に自動化された形でUBSanを強制稼働させ、リリース前に未定義動作を100%駆逐する」というパイプラインの構築である。

—

2. 妥協なき開発コンテナの構築：Dockerfileの極致

開発者のローカル環境依存を完全に排除し、CI環境と100%同一のバイナリを生成するため、コンテナベースの開発環境を定義する。ここでは、最新のLLVM/Clangツールチェーンを用い、UBSanの検知能力を最大限に高めたDocker環境を構築する。

==============================================================================
Ultra-Robust C/C++ Development & CI Container with UBSan
==============================================================================
FROM ubuntu:22.04 AS builder

必須パッケージのインストール（最新のLLVM/Clangツールチェーンを確保）
RUN apt-get update && apt-get install -y –no-install-recommends \
software-properties-common \
gnupg \
wget \
lsb-release \
git \
ninja-build \
cmake \
&& wget -O – https://apt.llvm.org/llvm-snapshot.gpg.key | apt-key add – \
&& add-apt-repository “deb http://apt.llvm.org/jammy/ llvm-toolchain-jammy-17 main” \
&& apt-get update && apt-get install -y –no-install-recommends \
clang-17 \
lld-17 \
llvm-17-dev \
libclang-17-dev \
&& rm -rf /var/lib/apt/lists/

デフォルトのコンパイラをClang-17に指定（ASan/UBSanの親和性が極めて高いため）
ENV CC=clang-17
ENV CXX=clang++-17

WORKDIR /workspace

ソースコードの配置
COPY . /workspace

ビルドディレクトリの作成とCMakeによる構成
UBSanとASanを同時に有効化し、未定義動作とメモリ破壊を同時に狩る
RUN mkdir -p build && cd build \
&& cmake -G Ninja \
-DCMAKE_C_FLAGS=”-fsanitize=address,undefined -fno-sanitize-recover=undefined -fno-omit-frame-pointer -gO2″ \
-DCMAKE_EXE_LINKER_FLAGS=”-fsanitize=address,undefined” \
.. \
&& ninja

このコンフィグの急所

• `-fno-sanitize-recover=undefined`: 未定義動作を検知した際、プログラムを即座にアボート（強制終了）させる。デフォルトでは警告を出して続行してしまうため、CI環境ではバグを隠蔽させないために必ず「回復不能」に設定すべきである。
• `-fno-omit-frame-pointer`: スタックトレースの精度を極限まで高め、クラッシュ時にどの関数のどの演算でUBを踏んだのかを正確に特定できるようにする。

—

3. GitHub ActionsによるCI/CDパイプラインへの完全統合

コンテナでビルドしたバイナリを、CI上で実行し、テストスイートを走らせる。もし1つでも未定義動作が検知されれば、即座にパイプラインを失敗させ、開発者にSlack等で通知する仕組みを構築する。

以下は、GitHub Actionsのワークフロー定義（`.github/workflows/ubsan-ci.yml`）である。

name: UBSan Execution Guard

on:
pull_request:
branches: [ main, develop ]
push:
branches: [ main, develop ]

jobs:
ubsan-verification:
name: Run UndefinedBehaviorSanitizer Checks
runs-on: ubuntu-latest

container:
image: ghcr.io/your-org/c-cpp-ubsan-env:latest
credentials:
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}

steps:

• name: Checkout Repository

uses: actions/checkout@v4

• name: Configure CMake with UBSan

run: |
mkdir -p build && cd build
cmake -G Ninja \
-DCMAKE_C_FLAGS=”-fsanitize=address,undefined -fno-sanitize-recover=undefined -fno-omit-frame-pointer -g” \
..

• name: Build Project

run: cmake –build build –parallel $(nproc)

• name: Execute Test Suite under UBSan Watch

run: |
cd build
# UBSanからの警告出力を厳格化する環境変数
export UBSAN_OPTIONS=”print_stacktrace=1:halt_on_error=1″

# テストバイナリの実行（ここでUBを踏むと非ゼロ終了コードを返す）
ctest –output-on-failure –timeout 300

運用上のキモ：`UBSAN_OPTIONS` のチューニング

実行時に渡している環境変数 `UBSAN_OPTIONS` は、ランタイムの挙動を制御する。

• `print_stacktrace=1`: UB検知時に必ず詳細なスタックトレースを標準エラー出力に吐き出す。
• `halt_on_error=1`: 最初のエラーを検知した瞬間にプロセスを停止させる（後続のノイズエラーを防ぎ、原因特定を容易にする）。

—

4. 現場で遭遇する「罠」とデバッグアプローチ

CI上でUBSanが火を噴き、以下のようなログが出力されたとする。ここからいかに迅速にデバッグを行うか、その実践知を共有する。

ログ解析の実例

/workspace/src/core/parser.c:142:35: runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type ‘int’
#0 0x4f8a12 in parse_packet /workspace/src/core/parser.c:142
#1 0x501b88 in process_stream /workspace/src/core/net.c:88
#2 0x4124c9 in main /workspace/src/app/main.c:21

このエラーは典型的な「符号付き整数のオーバーフロー」である。C言語の規格上、`int`のオーバーフローは未定義動作であり、コンパイラはこの条件が「絶対に起きない」という仮定のもとに最適化（Dead Code Eliminationなど）を行うため、意図しないセキュリティホールや暴走を引き起こす。

解決アプローチのステップ

1. 該当箇所の特定:
スタックトレースの `#0` に示された `/workspace/src/core/parser.c` の 142行目へ直行する。
2. コードの修正:
当該変数が負の値を取らない、あるいは十分に大きな型で表現されるべきであれば、明示的なキャストまたはサチュレーション演算、あるいは大きめの型（`int64_t`等）へのリファクタリングを行う。

// 修正前（UBの温床）
// int next_id = current_id + 1;

// 修正後（安全な演算チェック）
#include
#include

if (current_id == INT_MAX) {
// オーバーフロー回避のハンドリング
handle_overflow_error();
} else {
int next_id = current_id + 1;
}

3. サプレッション（抑制）ファイルの活用（どうしても修正できないレガシーコード向け）
サードパーティ製ライブラリ等でどうしても修正できないUBがある場合、あるいは一時的に特定の警告を目隠ししたい場合は、サプレッションファイル（`ubsan.supp`）を定義し、コンパイラに読み込ませる。

# ubsan.supp
signed-integer-overflow:third_party_lib.c

これをコンパイルフラグに付与する：
`-fsanitize-blacklist=/workspace/ubsan.supp`

(※ただし、DevOpsリードとして言及するならば、サプレッションの多用は技術的負債の蓄積を意味するため、原則として「全修正」をゴールとすべきである)

—

5. エキスパート向け：パフォーマンスチューニングとさらなる高みへ

もし、大規模なC/C++プロジェクト全体でUBSanを有効にした際に、テストの実行時間が耐えられないほど遅くなった場合は、以下のハックを適用せよ。

1. ターゲットを絞ったコンパイル（Fuzzingとの統合）

全テストケースでUBSanを有効にするのではなく、libFuzzerやAFL++と組み合わせたインメモリ・ファジング環境においてのみUBSanを極限まで効かせる。
ファジークライアントは、未知の入力を無限に生成するため、UBSanが検知する「整数オーバーフロー」や「不正なポインタ演算」をあぶり出すのに最も相性が良い。

ファザービルド時のUBSan有効化コマンド例
clang -fsanitize=fuzzer,address,undefined -gO2 fuzz_target.c -o fuzz_target

2. モジュール単位の選択的サニタイズ

CMakeを利用している場合、特定のパフォーマンスクリティカルなモジュール（例えばリアルタイム音声処理エンジン等）を除外し、コアロジックのみにUBSanを適用することも可能だ。

特定のソースファイル群に対してのみサニタイザーフラグを付与する
set_source_files_properties(src/core/parser.c PROPERTIES
COMPILE_FLAGS “-fsanitize=undefined”
)

—

総括

未定義動作は、コードベースにおける「見えない時限爆弾」である。いつ爆発するかはコンパイラのバージョンや最適化レベル、さらにはCPUの気分次第であり、デバッグは困難を極める。

UBSanをCI/CDパイプラインのなかに強制組み込みし、開発者のローカルからプロダクションリリースに至るまでの「防衛線」を構築すること。それこそが、モダンで強靭なC/C++開発環境を統括するDevOpsアーキテクトに課された使命である。

今日からあなたのパイプラインにも `-fsanitize=undefined` を組み込み、論理バグの芽を根絶やしにせよ。