こんにちは！日々のC言語コーディング、お疲れ様です。
いきなりですが、C言語で開発をしていて、こんな恐怖体験をしたことはありませんか？
- 「動的なデータ構造をゴリゴリ書いたはいいが、なぜか長時間動かすとメモリ使用量が右肩上がりになる……」
- 「断片化（フラグメンテーション）が起きて、まだ空きメモリがあるはずなのに `malloc` が突然 `NULL` を返す……」
- 「どこでメモリリークしているのか探そうにも、`valgrind` を使ったら実行速度が10倍に落ちてデバッグにならない……」
大規模な組み込み開発やゲームエンジン、リアルタイム処理システムにおいて、標準の `malloc`/`free` に頼りきったメモリ管理は、時としてプロジェクトを死に至らしめる隠れた爆弾になります。
今回は、GCCやClangが持つコンパイラのリンク時ラップ機能（`–wrap`）を使い、一切の外部ライブラリを入れずに、自前で超軽量かつ強力なメモリ断片化・リークの可視化ツールを作る方法を解説します。
これをマスターすれば、あなたのプログラムの「メモリの呼吸」が手に取るように見えるようになり、毎日のデバッグ作業が劇的に楽になりますよ。さあ、一緒に低レイヤの扉を開けましょう！
—
1. なぜ「標準の malloc」では戦えなくなるのか？
C言語の `malloc` や `free` は、OS（カーネル）からメモリを効率よく借りるために内部でヒープ領域を管理しています。しかし、一般的な汎用アロケータは「あらゆるサイズのリクエストに耐える」よう汎用化されているため、次のような弱点を持っています。
1. 外部断片化（External Fragmentation）:
細かい確保と解放を繰り返すと、メモリの隙間（空きブロック）が細切れになり、大きなメモリを確保しようとしたときに連続した領域が取れなくなる。
2. ブラックボックス性:
「今、システム全体で何バイト確保されていて、どの関数がそれを呼んだのか」がデフォルトでは追跡できない。
これを解決するために、「独自のカスタム・アロケータ（プール allocator やバディシステムなど）」を実装する前段階として、まずは現在の `malloc`/`free` の振る舞いを完全に“監視・インターセプト（横取り）”する仕組みを作りましょう。
—
2. コンパイラの魔術：`–wrap` オプションの仕組み
ここで登場するのが、GCCやClangのリンカが持つ `-Wl,–wrap,symbol` という強力な機能です。
このオプションをコンパイラ（リンカ）に伝えると、プログラム内の `malloc` や `free` の呼び出しを、自動的に自作の関数 `__wrap_malloc` や `__wrap_free` にすり替えてくれます。さらに、元の関数を呼びたいときは `__real_malloc` を使えばそのままアクセスできます。
[ あなたのコード ]
│
▼ (mallocを呼ぶ)
[ リンカの魔法: –wrap=malloc ]
│
├─► [ 自作のラップ関数: __wrap_malloc ] ──► (ログ記録・統計計算)
│ │
│ ▼ (必要なら元を呼ぶ)
└────────────────────────────────────────► [ 本物の関数: __real_malloc ]
この仕組みを使えば、既存のソースコードを1行も書き換えることなく、すべてのメモリ割り当てを完全にコントロール下におけるのです。
—
3. 実装：リアルタイム・メモリ可視化プロファイラ
それでは、実際に動くコードを見ていきましょう。
以下の2つのファイルを作成してください。
① 監視用ラッパー実装：`mem_profiler.c`
このファイルが、すべての `malloc`/`free` を監視し、メモリの使用状況や断片化の兆候を記録します。
define _GNU_SOURCE
include
include
include
include
// 現在確保されている総バイト数
static size_t g_current_allocated = 0;
// 過去最大で確保された総バイト数（ピークメモリ）
static size_t g_peak_allocated = 0;
// mallocが呼ばれた総回数
static size_t g_alloc_count = 0;
// freeが呼ばれた総回数
static size_t g_free_count = 0;
// リンカによってラップされる本物のmallocの宣言
void __real_malloc(size_t size);
// リンカによってラップされる本物のfreeの宣言
void __real_free(void ptr);
// 自作のラップ版 malloc
void __wrap_malloc(size_t size) {
// メタデータ（サイズ情報など）を格納するために少し多めにメモリを要求する
// ※実務の高度なアロケータではここにガードバイトやファイル名を仕込みます
size_t augmented_size = size + sizeof(size_t);
void ptr = __real_malloc(augmented_size);
if (!ptr) {
fprintf(stderr, “[MemProfiler] ERROR: Out of memory!\n”);
return NULL;
}
// 先頭の領域に確保サイズを埋め込む（free時にサイズを特定するため）
(size_t)ptr = size;
void user_ptr = (void)((uint8_t)ptr + sizeof(size_t));
// 統計情報の更新（スレッドセーフティを考慮するならここでmutex等を使います）
g_current_allocated += size;
g_alloc_count++;
if (g_current_allocated > g_peak_allocated) {
g_peak_allocated = g_current_allocated;
}
// デバッグ用出力（どのような割り当てが行われているかリアルタイムで可視化）
printf(“[ALLOC] 0x%p (%zu bytes) | Current: %zu bytes (Peak: %zu bytes)\n”,
user_ptr, size, g_current_allocated, g_peak_allocated);
return user_ptr;
}
// 自作のラップ版 free
void __wrap_free(void ptr) {
if (!ptr) return;
// ユーザーポインタからメタデータ（サイズ）の位置を逆算する
void real_ptr = (void)((uint8_t)ptr – sizeof(size_t));
size_t size = (size_t)real_ptr;
// 統計情報の更新
g_current_allocated -= size;
g_free_count++;
printf(“[FREE ] 0x%p (%zu bytes) | Current: %zu bytes\n”,
ptr, size, g_current_allocated);
// 本物のfreeに渡してメモリを返却
__real_free(real_ptr);
}
// プログラム終了時にメモリリークや断片化のサマリーを出力する関数
__attribute__((destructor)) static void mem_profiler_report(void) {
printf(“\n========================================\n”);
printf(” MEM_PROFILER EXECUTION REPORT \n”);
printf(“========================================\n”);
printf(“Total Allocations : %zu times\n”, g_alloc_count);
printf(“Total Frees : %zu times\n”, g_free_count);
printf(“Peak Memory Usage : %zu bytes\n”, g_peak_allocated);
printf(“Leaked Bytes : %zu bytes\n”, g_current_allocated);
if (g_current_allocated > 0) {
printf(“[WARNING] Memory leak detected! Clean up your garbage!\n”);
} else {
printf(“[SUCCESS] No memory leaks detected. Great job!\n”);
}
printf(“========================================\n”);
}
② テスト用プログラム：`main.c`
意識的にメモリを確保したり解放したり、あるいはわざとリークさせたりするコードです。
include
include
int main(void) {
printf(“— Test Program Start —\n”);
// 1. 小さなメモリをいくつか確保
char p1 = (char)malloc(128);
int p2 = (int)malloc(sizeof(int) 100);
// 2. メモリを解放
free(p1);
// 3. 少し大きなメモリを確保（断片化のシミュレーション）
char p3 = (char)malloc(1024);
// 4. クリーンアップ
free(p2);
// あえて p3 の解放を忘れてみる（メモリリークの発生）
// free(p3);
printf(“— Test Program End —\n”);
return 0;
}
—
4. 実行とコンパイル：GCC/Clangの魔法をかける
ここが一番重要なポイントです。通常のコンパイルではなく、リンカに対して「`malloc` と `free` をラップしろ」と明示的に指示を与えます。
以下のコマンドをターミナルで実行してください。
GCCまたはClangを使ってコンパイル＆リンクを行う
gcc -Wall -Wextra -O2 mem_profiler.c main.c \
-Wl,–wrap,malloc \
-Wl,–wrap,free \
-o mem_test
💡 コマンドの解説
- `-Wl,–wrap,malloc`: リンカ（ld）に対し、`malloc` の呼び出しを `__wrap_malloc` に置き換えるよう指示します。
- `-Wl,–wrap,free`: 同様に、`free` の呼び出しを `__wrap_free` に置き換えます。
- `__attribute__((destructor))`: `mem_profiler.c` 内のレポート関数にこれを付与することで、`main` 関数が終了した直後（プログラムが終了する間際）に自動的に統計レポートが走るようになっています。
実行結果の確認
それでは、ビルドしたバイナリを実行してみましょう。
$ ./mem_test
次のような美しいログがコンソールに出力されるはずです。
— Test Program Start —
[ALLOC] 0x7ffd58123020 (128 bytes) | Current: 128 bytes (Peak: 128 bytes)
[ALLOC] 0x7ffd581230b0 (400 bytes) | Current: 528 bytes (Peak: 528 bytes)
[FREE ] 0x7ffd58123020 (128 bytes) | Current: 400 bytes
[ALLOC] 0x7ffd58123200 (1024 bytes) | Current: 1424 bytes (Peak: 1424 bytes)
[FREE ] 0x7ffd581230b0 (400 bytes) | Current: 1024 bytes
— Test Program End —
========================================
MEM_PROFILER EXECUTION REPORT
========================================
Total Allocations : 3 times
Total Frees : 2 times
Peak Memory Usage : 1424 bytes
Leaked Bytes : 1024 bytes
[WARNING] Memory leak detected! Clean up your garbage!
========================================
おめでとうございます！ ソースコードのビジネスロジック（`main.c`）に一切手を加えることなく、どのタイミングで何バイト使われ、最終的にどこがリークしたのかが完璧に可視化されました。
—
5. 現場のアーキテクトからの実践的なアドバイス
この手法をさらに発展させると、実務の現場では次のような強力なカスタム・アロケータやデバッグ基盤に進化させることができます。
1. コールスタックの記録（`backtrace` の活用）:
`__wrap_malloc` の内部で `
2. ガードゾーン（境界領域）の設定:
確保したメモリの直前・直後に特定の魔術数値（マジックナンバー）を書き込んでおき、`free` 時にそれが書き換わっていないかをチェックすることで、バッファオーバーラン（領域外書き込み）を即座に検知するデバッグアロケータが作れます。
C言語のメモリ管理は一見すると荒涼とした広野のように思えますが、コンパイラの仕様とリンクの仕組みを深く理解すれば、自分だけの強力な計器を作り出すことができます。
「メモリがどう動いているかが見える」ようになると、C言語を書くことが驚くほど楽しく、そして確実になります。ぜひ、あなたの開発環境やプロジェクトにもこのプロファイリング手法を取り入れてみてください。毎日のコーディングが、きっと劇的に変わりますよ！