Zend APIとC拡張開発の深淵：zval参照カウントの掌握とValgrindによるメモリリーク撃破の極意
PHPのコードレビューにおいて、「なぜその実装が危険なのか」をロジカルに説明できるエンジニアはどれほどいるだろうか。PHPは高級言語であり、開発者は普段、メモリ管理やガベージコレクションの存在を意識する必要がない。しかし、ひとたびシステムのスループット限界を突破するためにZend APIを用いたC言語によるネイティブ拡張開発（PECL/Zend Extension）の領域に踏み入れた途端、我々はZend VMのメモリ管理モデルの生々しい現実と対峙することになる。
Zend VMの中核をなすのは、あらゆるPHPの変数を包み込むデータ構造 `zval`（Zend Value）である。この `zval` の参照カウント（`refcount`）やGCのメカニズムを誤ってハンドリングすれば、即座にSegmentation Fault（セグフォルト）によるプロセス急死、あるいはWebサーバープロセス（PHP-FPM）全体を蝕む深刻なメモリリークを引き起こす。
本稿では、Zend APIにおける `zval` 操作の暗部を暴き、実務で絶対に避けるべきアンチパターンと、それを検知・駆逐するためのValgrind解析の極意を、テクニカルリードの視点からシャープに伝授する。
—
1. Zend VMの基礎：`zval` と参照カウントの物理構造
PHP 7以降、`zval` の構造体サイズは16バイトに最適化され、値のインライン化とポインタの効率的な管理が実現された。PHP 8現在においても、その基本思想は変わらない。
typedef struct _zval_struct zval;
struct _zval_struct {
zend_value value;u // 8バイト: 実データ（long, double, zend_string, zend_array など）
union {
struct {
ZEND_ENDIAN_LOHI_4(
zend_uchar type, // 1バイト: 変数型（IS_LONG, IS_STRING, IS_ARRAY 等）
zend_uchar type_flags, // 1バイト: 型フラグ（GCフラグなど）
zend_uchar const_flags, // 1バイト: 定数フラグ
zend_uchar reserved // 1バイト: 予約領域
)
} v;
uint32_t type_info;
} u1;
union {
uint32_t ptr_count; // 1バイト/4バイト: 参照カウント等
zend_ast_ref ast; // ASTノード
zend_long h; // ハッシュ値
zend_object_handlers handlers;
zend_class_entry ce;
zend_function func;
uint32_t refcount; // 参照カウント（主に参照やリソース用）
} u2;
};
C拡張からPHPの変数を受け取り、あるいは生成してPHP側へ返す際、この `zval` の「借用（Borrow）」と「所有権の移転（Move）」の境界線を正確に引けなければ、メモリ破壊は不可避となる。
よくある致命的ミス：`Z_ADDREF_P` の過剰呼出しと解放漏れ
C拡張内でPHPから渡された配列や文字列を操作する際、参照カウントをインクリメント（`Z_ADDREF_P`）したものの、処理終了時にデクリメント（`Z_DELREF_P` あるいは `zval_ptr_dtor`）を忘れるケースが後を絶たない。これが1リクエスト中、あるいはロングランプロセス（SwooleやRoadRunnerなど）で発生すると、瞬く間にメモリが枯渇する。
—
2. 実務で耐えうるC拡張の実装パターン：安全な `zval` 操作
ここでは、C拡張側でPHPの配列を受け取り、要素を安全に操作して返却する関数を実装する。メモリリークを完全に排除した模範的なコードを見てほしい。
php_extension_demo.c
include “php.h”
/
- 概要: PHP側から受け取った配列の各要素を安全に走査し、
- 新しい配列として返却するC拡張関数のサンプル
/
PHP_FUNCTION(demo_process_array)
{
zval input_array;
zval value;
zend_string key;
zend_ulong idx;
HashTable ht;
/ パラメータのパース: 配列のみを受け付ける /
if (zend_parse_parameters(ZEND_NUM_ARGS(), “a”, &input_array) == FAILURE) {
RETURN_THROWS();
}
/ 返却用の新しい配列（zval）を初期化 /
array_init(return_value);
/ 入力配列のHashTableを取得 /
ht = Z_ARRVAL_P(input_array);
/
- ハッシュテーブルの内部ポインタを走査
- ⚠️注意: ここで要素のzvalを直接操作する場合、参照カウントの扱いに細心の注意を払う
/
ZEND_HASH_FOREACH_KEY_VAL(ht, idx, key, value) {
zval new_val;
/
- プリミティブな型（Longなど）の場合、値の複製（コピー）を作成するのが最も安全。
- 参照をそのまま渡すと、PHPスクリプト側での意図しない副作用を生む可能性がある。
/
ZVAL_COPY(&new_val, value);
/ 何らかの加工処理（例: 値を2倍にする） /
if (Z_TYPE(new_val) == IS_LONG) {
Z_LVAL(new_val) = 2;
}
/
- 新しい配列へ追加
- add_assoc_zval_ex は内部で zval の参照カウントを適切にインクリメントするため、
- 追加元の new_val は呼び出し側で破棄（dtor）する必要がある。
/
if (key) {
add_assoc_zval_ex(return_value, ZSTR_VAL(key), ZSTR_LEN(key), &new_val);
} else {
add_index_zval(return_value, idx, &new_val);
}
} ZEND_HASH_FOREACH_END();
}
コードレビューの急所：なぜ `ZVAL_COPY` と `add_assoc_zval_ex` なのか？
1. 所有権の明確化: `ZVAL_COPY` を使用することで、元の `zval` の参照カウントを安全にインクリメント（または実体を複製）し、拡張独自のスコープで独立した `new_val` を確保している。
2. デストラクタの連鎖: `add_assoc_zval_ex` はハッシュテーブルに `zval` を挿入する際、その所有権をハッシュテーブル側に移譲する。これにより、PHP側で配列が破棄されたときに、内部の要素も自動的に `zval_ptr_dtor` によって安全に解放される。
—
3. Valgrindによるメモリリーク解析の実践
C拡張開発において、コンパイルが通ったという事実メンタルモデルの安心感は何の保証にもならない。メモリリークや不正なメモリ読み書き（Use-After-Free）を暴く唯一の絶対的な武器が Valgrind である。
しかし、PHPのメモリ管理は独自のヒープマネージャー（Zend MM）を介して行われるため、デフォルトのままではZend MMが内部プールしているメモリがすべて「リークしている」とValgrindに誤認されてしまう。これを防ぐために、Pure Memory Manager（Zend MMをバイパスする設定）を有効にしてデバッグを行う必要がある。
1. デバッグ用PHPのビルドと環境変数設定
Valgrindで正確なスタックトレースを得るためには、Zend MMを無効化（`ZEND_DONT_UNLOAD_MODULES=1` や `USE_ZEND_ALLOC=0`）してコンパイル・実行する必要がある。
Zend Memory Managerを無効化してPHPを実行する環境変数
export USE_ZEND_ALLOC=0
2. Valgrindコマンドの実行
以下のように、PHPスクリプトをValgrind経由で直に実行し、メモリリークを検知する。
valgrind –leak-check=full \
–show-leak-kinds=all \
–track-origins=yes \
–dsymutil=yes \
php -d zend_extension=/path/to/your_extension.so \
-r ‘$a = [1, 2, 3]; demo_process_array($a);’
3. Valgrind出力結果の読み解き方（実例）
もし、前述のコードで `new_val` の解放漏れや、`zval` のデクリメント忘れがあった場合、Valgrindは以下のような鋭い警告を発する。
==12345== HEAP SUMMARY:
==12345== in use at exit: 72,704 bytes in 142 blocks
==12345== total heap allocs: 1,532 operations, 1,389 frees, 456,800 bytes allocated
==12345==
==12345== 16 bytes in 1 blocks are definitely lost in loss record 12 of 35
==12345== at 0x4C2AB80: malloc (vg_replace_malloc.c:299)
==12345== by 0x7FFF8123: zend_string_alloc (zend_string.h:133)
==12345== by 0x7FFF8456: zim_demo_process_array (php_extension_demo.c:42)
==12345== …
==12345==
==12345== LEAK SUMMARY:
==12345== definitely lost: 16 bytes in 1 blocks
この出力から、`php_extension_demo.c` の42行目（`zim_demo_process_array` 内）で確保された `zend_string` が解放されずにプロセス終了を迎えていることが一目瞭然となる。このように、「どのCの関数名の何行目でメモリが確保され、解放されなかったか」をピンポイントで特定し、コード上の `zval_ptr_dtor()` や `efree()` の配置漏れを修正していく。
—
4. テクニカルリードからの最終提言
PHP拡張開発は、Zend VMの内部構造とメモリモデルをダイレクトに操作できるため、極限のパフォーマンスを引き出すことができる諸刃の剣である。
- 変数を扱うときは常に「その `zval` の所有権は誰にあるのか（PHPスクリプトか、C拡張のローカルスコープか、あるいはHashTableか）」を自問すること。
- 参照カウントを操作するマクロ（`Z_ADDREF_P`, `Z_DELREF_P`, `zval_ptr_dtor`）は、その挙動を物理レベルで理解していない限り使ってはならない。
- 本番環境へデプロイする前に、必ず `USE_ZEND_ALLOC=0` を冠したValgrindによるストレステストをCIパイプライン、あるいは検証環境のルーチンに組み込むこと。
この規律を遵守できたとき初めて、あなたの書いたC拡張は、数千万リクエストを捌く巨大Webシステムの心臓部として、一分の隙もなく、美しく、そして猛烈な速度で稼働し続ける資格を得るのだ。