Zend APIの深淵：zval参照カウントの崩壊と、ValgrindによるC拡張メモリデバッグの極意
PHPという言語は、そのエレガントな構文の裏側で、極めて洗練された、そして時に残酷なまでのC言語のメモリ管理の上に成り立っている。私たちが日常的に書く `$a = $b;` という何気ない代入一つをとっても、Zend VMの内部では `zval`（Zend Value）構造体の生成、型情報の付替、そして参照カウント（refcount）の原子的な操作が行われている。
Webアプリケーションの規模が拡大し、極限のパフォーマンスが求められるようになると、開発者はPHPの標準的な機能の枠を超え、C言語によるZend拡張（Extension）の開発に手を伸ばすことになる。C拡張はJITすら凌駕する圧倒的な実行速度をもたらすが、それは同時に、PHPがこれまで隠蔽してくれていた「メモリ管理の生々しい責任」のすべてを、エンジニア自身が背負うことを意味する。
本稿では、Zend APIを用いたC拡張開発において最も頻発し、かつ最も検知が困難な「zvalの参照カウント操作ミスによるメモリリークおよび二重解放（Double Free）」を取り上げ、Zend VMの内部構造とValgrindを用いた極限のデバッグ手法を徹底的に解説する。
—
1. Zend VMの基盤：`zval` と参照カウントの物理構造
PHP 7以降、`zval` の構造体サイズは一律16バイト（64bit環境）に最適化され、値そのものを保持するのではなく、プリミティブ型は値（インライン値）を直接持ち、配列（`HashTable`）やオブジェクト（ズエンド・オブジェクト）などの複合型はヒープ上の実体を指し示すポインタを保持する設計となった。
typedef struct _zval_struct {
другому u {
zend_long lval; / 長整数 /
double dval; / 浮動小数点数 /
zend_refcounted counted; / ヒープ上の構造体へのポインタ /
zend_string str;
zend_array arr;
zend_object obj;
zend_resource res;
zend_reference ref;
// … その他の共用体
} value;
union {
uint32_t type_info; / 型情報と修飾子 /
} u1;
union {
uint32_t var_flags;
uint32_t next;
uint32_t cache_slot;
uint32_t opline_num;
} u2;
} zval;
ここで重要なのが、複合型や参照型が持つ `GC` ヘッダ、すなわち参照カウント（`gc.refcount`）である。
Zend VMは、メモリの効率化とCopy-on-Write（COW）を実現するために、この `refcount` を厳密にインクリメント・デクリメントしている。
C拡張内で自作関数やリソースを実装する際、この `refcount` のライフサイクルを1つでも誤ると、以下の致命的な障害を引き起こす。
1. メモリリーク（Memory Leak）: ポインタの所有権（Ownership）を放棄したにもかかわらず `Z_TRY_ADDREF_P` を呼び続けたり、`zval` の解放時に適切な `zval_ptr_dtor()` を呼ばなかった場合、FPMの1リクエスト終了後もプロセス内にメモリが残留し、徐々にサーバーのRAMを食いつぶす。
2. 不正アクセス / セグメンテーション違反（Segmentation Fault）: すでに破棄された `zval` や `zend_string` を指し続ける野良ポインタ（Dangling Pointer）にアクセスし、最悪の場合はリモートコード実行（RCE）の踏み台となる脆弱性を生む。
—
2. 破壊的なバグの典型例：誤った zval 操作
以下のC拡張コード片を見てほしい。一見すると、PHPから渡された引数の文字列を受け取り、何らかの処理をして返すだけの無害なコードに見える。
/ 致命的なバグを含むC拡張のサンプル関数 /
PHP_FUNCTION(inefficient_dup_string)
{
zval arg;
zend_string str_val;
/ 引数を安全にパースする /
if (zend_parse_parameters(ZEND_NUM_ARGS(), “z”, &arg) == FAILURE) {
RETURN_THROWS();
}
/ 引数が文字列であるか検証し、zend_stringを取得 /
if (Z_TYPE_P(arg) != IS_STRING) {
RETURN_FALSE;
}
str_val = Z_STR_P(arg);
/ 【誤り】参照カウントをインクリメントせずに内部構造体を流用し、さらに手動で確保したメモリを返す /
zend_string new_str = zend_string_copy(str_val);
/ 戻り値用のzvalに文字列を設定するが、refcountの整合性が狂う /
RETVAL_STR(new_str);
/ 注意: ここで本来不要なzvalの解放や、逆に必要なdtorの欠落がメモリリークを誘発する /
}
このコードの何が問題か。`zend_string_copy()` は内部で `GC_REFCOUNT` をアトミックにインクリメントする。しかし、C拡張の開発者は往々にして「PHPのメモリ管理マクロ」と「ZendMM（Zend Memory Manager）の直接呼び出し」を混同し、`RETVAL_STR` や `RETURN_STRING` の内部挙動との間で参照カウントの辻褄を見失うのだ。
結果として、PHPスクリプト側でその関数を実行した瞬間に、OPcacheやZend VMのガーベジコレクション（GC）サイクルが崩壊し、FPMの子プロセスが静かにクラッシュする。エラーログには `zend_mm_heap corrupted` という絶望的なメッセージだけが残されることになる。
—
3. Valgrindを用いた極限のメモリデバッグ手法
Zend VM内部のメモリ破壊やリークを特定するには、標準的なデバッガ（GDB）だけでは不十分である。PHPエンジン自体がアロケータ（ZendMM）を独自に持っており、OSの `malloc`/`free` をラップしているため、そのままではリーク箇所が正確に見えない。
ここで登場するのが Valgrind、特にそのツールである Memcheck である。
デバッグ用PHPバイナリのビルド
Valgrindを正確に機能させるためには、ZendMMの独自アロケータを無効化し、OS標準の `malloc`/`free` を直接使わせるフラグを立ててPHPをソースからビルドする必要がある。
ZendMMを無効化（ZEND_DEBUG=1 および USE_ZEND_ALLOC=0）してビルド
export CFLAGS=”-O0 -g3″
./configure –disable-all –enable-cli –enable-debug
make -j$(nproc)
この状態で、作成したC拡張をロードしたPHPスクリプトをValgrind経由で実行する。
USE_ZEND_ALLOC=0 valgrind \
–leak-check=full \
–show-leak-kinds=all \
–track-origins=yes \
–suppressions=/path/to/php/sapi/cli/valgrind.supp \
sapi/cli/php -d extension=./modules/my_extension.so -r ‘my_extension_func(“test”);’
Valgrind出力結果の読み解き
コンソールに吐き出されたレポートの中に、以下のような記述を見つけたら、それはC拡張における `zval` または `zend_string` の参照カウント操作ミスの確実な証拠である。
==12345== Invalid read of size 8
==12345== at 0x5F1A2B: zend_string_addref (zend_types.h:450)
==12345== at 0x5F3C10: zim_my_extension_func (my_extension.c:42)
==12345== Address 0x7ffd12a8 is 0 bytes inside a block of size 24 free’d
==12345== at 0x4C3217F: free (vg_replace_malloc.c:540)
==12345== at 0x6A1120: _efree (zend_alloc.c:2450)
==12345== by 0x62011F: zend_string_free (zend_string.h:132)
「`Invalid read of size 8`」および「`free’d`」のログは、すでに `zend_string_free()` 等によって解放され、参照カウントが0になり消滅したヒープ領域に、C拡張側がポインタ経由でアクセスしようとした（ダングリングポインタ）ことを示している。
これを修正するには、Zend APIのルールに則り、次のように明示的な参照カウントの管理と `Z_ADDREF_P` / `zval_ptr_dtor()` のペアを正しく記述しなければならない。
/ 正しいzvalおよびzend_stringのハンドリング例 /
PHP_FUNCTION(safe_dup_string)
{
zval arg;
zend_string str_val;
if (zend_parse_parameters(ZEND_NUM_ARGS(), “z”, &arg) == FAILURE) {
RETURN_THROWS();
}
if (Z_TYPE_P(arg) != IS_STRING) {
RETURN_FALSE;
}
str_val = Z_STR_P(arg);
/ 参照カウントを安全にインクリメントして新しいzend_stringを保持 /
zend_string_addref(str_val);
/ 戻り値として安全に渡す /
RETVAL_STR(str_val);
}
—
4. チーフアーキテクトからの提言：C拡張開発の限界とセキュリティ
C言語を用いたZend拡張の開発は、PHPの限界を突破する究極の手段であると同時に、ひとたび実装を誤れば、Webアプリケーション全体を致命的な脆弱性に晒すリスクを孕む。
特に、参照カウントの操作ミスによるヒープオーバーフローやUse-After-Freeは、悪意ある攻撃者によって巧妙に利用され、最終的にはPHPプロセスのメモリ空間を書き換えられてリモートコード実行（RCE）のガジェットチェーンへと結びつけられる。
高負荷なWebシステムを設計する現代のアーキテクトにとって、PHPコアの挙動、Zend VMのオペコード実行、そしてメモリ管理のプリミティブな仕組みを完全に掌握していることこそが、真に堅牢で高速なシステム構築を成し遂げるための唯一にして最大の武器となる。
フレームワークのレイヤーを超え、Zendエンジンそのものの鼓動を感じ取れ。低レイヤの支配こそが、エンジニアリングの極みである。