レガシー第18章：自作メモリリーク検知器とクラッシュダンプ解析

• ゼロリークの鉄則: 家庭用ゲーム機やスマホゲームでは、長時間の連続稼働に耐えるため1バイトのメモリリークも許容されない。
• 確保コンテキストの保存: アドレスとサイズだけでなく、ファイル名・行番号のメタデータを確保ヘッダに紐付けることでデバッグが劇的に容易になる。

### 「new」式 と 「operator new」の決定的な違い

C++初心者最大の混乱ポイントがこれです：

1. **「new」式（言語仕様・構文）**:
Enemy* e = new Enemy();
これはコンパイラによって以下の2段階の処理に変換されます：
- ステップA: void* mem = operator new(sizeof(Enemy)); （メモリ確保関数）
- ステップB: Enemy::Enemy() をそのメモリ上で実行（コンストラクタ呼び出し）

2. **「operator new」（ただの関数）**:
メモリの生バイト領域を確保して返すだけの関数（malloc に近い）。
**我々がオーバーロードできるのは、このステップAの関数なのです！**

#ifndef MEMORY_TRACKER_HPP
#define MEMORY_TRACKER_HPP

#include <cstdlib>
#include <iostream>

// 確保されたメモリブロックの先頭に付与するメタデータ
struct MemoryHeader {
    size_t size;
    const char* filename;
    int line;
    MemoryHeader* next;
    MemoryHeader* prev;
};

// グローバルなリンクリスト先頭
extern MemoryHeader* g_allocatedHead;
extern size_t g_totalAllocatedBytes;

// デバッグ用 operator new（ファイル名と行番号を受け取る）
void* operator new(size_t size, const char* filename, int line);
void* operator new[](size_t size, const char* filename, int line);

// 通常の delete
void operator delete(void* ptr) throw();
void operator delete[](void* ptr) throw();

// デバッグビルド時のみ new を置換するマクロ
#if defined(_DEBUG) || !defined(NDEBUG)
    #define DEBUG_NEW new(__FILE__, __LINE__)
    #define new DEBUG_NEW
#endif

// リークレポート出力関数
void dumpMemoryLeaks();

#endif

• new式とoperator newの明確な区別: new式はメモリ確保＋コンストラクタ実行。オーバーライドできるのはメモリ確保関数である operator new。
• ヘッダープレフィックス技法: 確保要求サイズより少し大きな領域を取り、先頭にメタデータを格納してポインタをずらして返すのがアロケータの定石。

#include <iostream>
#include <cstdlib>

struct MemoryBlock {
    size_t size;
    const char* file;
    int line;
    MemoryBlock* next;
};

static MemoryBlock* g_head = NULL;

void* my_alloc(size_t size, const char* file, int line) {
    // ヘッダー分余計に確保
    size_t total = sizeof(MemoryBlock) + size;
    MemoryBlock* blk = (MemoryBlock*)std::malloc(total);
    blk->size = size;
    blk->file = file;
    blk->line = line;
    blk->next = g_head;
    g_head = blk;
    
    // データ領域へのポインタを返す
    return (void*)(blk + 1);
}

void my_free(void* ptr) {
    if (!ptr) return;
    MemoryBlock* target = ((MemoryBlock*)ptr) - 1;
    
    // リストから除外（簡易実装）
    if (g_head == target) {
        g_head = target->next;
    } else {
        MemoryBlock* curr = g_head;
        while (curr && curr->next != target) {
            curr = curr->next;
        }
        if (curr) curr->next = target->next;
    }
    std::free(target);
}

void reportLeaks() {
    std::cout << "
=== Memory Leak Report ===" << std::endl;
    int count = 0;
    MemoryBlock* curr = g_head;
    while (curr) {
        std::cout << "[LEAK] File: " << curr->file 
                  << ", Line: " << curr->line 
                  << ", Size: " << curr->size << " bytes" << std::endl;
        count++;
        curr = curr->next;
    }
    if (count == 0) {
        std::cout << "✨ Perfect! 0 bytes leaked." << std::endl;
    } else {
        std::cout << "❌ Total " << count << " leak(s) found!" << std::endl;
    }
}

int main() {
    // 正常な確保と解放
    int* p1 = (int*)my_alloc(sizeof(int) * 10, "main.cpp", 57);
    my_free(p1);

    // 意図的な解放忘れ（リーク発生！）
    char* leak1 = (char*)my_alloc(64, "Player.cpp", 108);
    double* leak2 = (double*)my_alloc(sizeof(double) * 2, "Enemy.cpp", 215);

    // プログラム終了時にリーク一覧を出力
    reportLeaks();

    // 後片付け
    my_free(leak1);
    my_free(leak2);
    return 0;
}

• 自己参照アロケーションの回避: メモリアロケータ自身が動的メモリを要求すると無限ループに陥るため、固定長ヘッダや自前リンクリストで完結させる。
• 継続的インテグレーション（CI）への組み込み: 自動テスト終了時にリーク検知器が0件であることをアサートすることで、メモリリークのマスターブランチ混入を未然に防ぐ。

• PDBシンボルファイルの厳重保管: リリースビルドのバイナリと完全に一致するデバッグシンボル（PDBファイル）がなければ、ダンプファイルからソースコード行を復元できない。

• 1. コンストラクタの実行タイミングのみ
• 2. メモリ領域の生バイトを確保する関数 operator new(size_t) のみ
• 3. C++コンパイラの字句解析フェーズのみ
• 4. CPUのL1キャッシュ制御命令のみ

正解と解説を見る

正解：メモリ領域の生バイトを確保する関数 operator new(size_t) のみ
new 式は「operator new によるメモリ確保」と「コンストラクタ呼び出し」の2段階で構成され、プログラマがオーバーロードできるのは前者の operator new 関数です。

• 1. #define new new(__FILE__, __LINE__)
• 2. #define delete exit(0)
• 3. #define malloc free
• 4. #pragma once

正解と解説を見る

正解：#define new new(__FILE__, __LINE__)
__FILE__ と __LINE__ はコンパイル時に現在のソースファイル名と行番号に置換される定義済みマクロであり、これらを operator new の追加引数として渡すことで確保元を記録できます。

• 1. STLを使うとC++のライセンス料が発生するため
• 2. STL内部で new が呼ばれ、トラッカー自身が自分自身を呼び出して無限再帰やデッドロックに陥る危険があるため
• 3. STLを使うと画面の解像度が低下するため
• 4. std::vector はC言語でコンパイルできないため

正解と解説を見る

正解：STL内部で new が呼ばれ、トラッカー自身が自分自身を呼び出して無限再帰やデッドロックに陥る危険があるため
カスタムアロケータ内で標準STLコンテナを使うと、そのコンテナがさらにメモリを要求して operator new を呼び出し、無限再帰クラッシュを引き起こします。

• 1. ゲームのBGMサウンドファイル（.wav）
• 2. ビルド時に生成されたデバッグシンボルファイル（Windowsでは.pdb、Linuxでは.sym等）
• 3. ゲームのREADME.txtファイル
• 4. GPUのディスプレイドライバインストーラ

正解と解説を見る

正解：ビルド時に生成されたデバッグシンボルファイル（Windowsでは.pdb、Linuxでは.sym等）
シンボルファイル（.pdb）には機械語のアドレスとソースコードのファイル名・行番号・変数名の対応関係が記録されており、クラッシュダンプ解析に必須です。