Node.jsの「不可解なクラッシュ」を制圧する：Core Dumpとllhttpによる深層診断術
プロダクション環境でNode.jsが「理由なともなく」再起動を繰り返す。`Error: write EPIPE` や `Segmentation fault` がログに一行残るだけ。多くのエンジニアはここで「メモリリークか？」と推測し、安易な再起動やリソース増強で誤魔化します。しかし、これはアーキテクトとしては失格です。
Node.jsのランタイム内部で何が起きているのか。C++レベルのスタックトレースを読み解き、`llhttp`（Node.jsのHTTPパーサー）がどのようなHTTPパケットで破壊されたのかを突き止める。本稿では、そんな「最後の砦」となる診断技術を伝授します。
—
1. 「墜落の瞬間」を封じ込める：Core Dumpの設計
クラッシュした瞬間にプロセスを終了させるだけでは、原因究明は不可能です。OSレベルでメモリの状態を保存する「Core Dump」を生成する設定が不可欠です。
システム側の事前準備
まずはLinuxカーネルがコアダンプを許可しているか確認します。Docker環境であっても、ホスト側の制限がボトルネックになることが多いため、必ず `ulimit` を設定してください。
実行中のシェルのコアダンプ制限を無制限に設定
ulimit -c unlimited
コンテナ起動時に –ulimit core=-1 を付与することをチームの共通ルールとする
docker run –ulimit core=-1 …
Node.js側のトリガー設定
アプリケーション起動時に、未捕捉の例外や重大なエラーが発生した際、即座にコアダンプを生成するフラグを付与します。
–abort-on-uncaught-exception: 未捕捉例外でプロセス終了時にダンプ出力
–max-old-space-size: メモリ枯渇を意図的に引き起こす場合の閾値設定
node –abort-on-uncaught-exception –max-old-space-size=2048 app.js
—
2. `lldb` による深層解剖：スタックトレースの向こう側
コアダンプファイル（`core`）が生成されたら、`lldb`（または `gdb`）を使ってC++スタックを追いかけます。ここで重要なのは、Node.js本体のデバッグシンボルがインストールされていることです。
解析の手順
1. プロセスとダンプファイルを紐付ける
`lldb $(which node) -c core`
2. JavaScriptのスタックを復元する
`lldb` 内でNode.jsのデバッグ用マクロを読み込みます。
lldb内部で実行
(lldb) source /path/to/node/tools/lldb_commands.py
JSのスタックトレースを表示
(lldb) v8 bt
これで、C++の関数呼び出しの裏にある「どのJSコードでクラッシュしたか」が判明します。もし `llhttp_execute` 周りでクラッシュしているなら、クライアントから送られてきた不正なHTTPヘッダーがパーサーを破壊しています。
—
3. 開発スピードを加速させる「神プラグイン」と「IDE設定」
診断に時間をかけないためには、日常のコーディングからデバッグへの距離を0にする必要があります。
VS Code設定の共有化（.vscode/settings.json）
プロジェクトルートにこれを置くことで、チーム全員が同じデバッグ環境で作業できるようになります。
{
“launch”: {
“version”: “0.2.0”,
“configurations”: [
{
“type”: “node”,
“request”: “launch”,
“name”: “Debug Current File”,
“skipFiles”: [“
“runtimeArgs”: [“–inspect”], // Chrome DevToolsでの接続を許可
“console”: “integratedTerminal”
}
]
}
}
推奨プラグイン
- [ESLint](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint): `plugin:node/recommended` を設定。ランタイムの破壊的変更を事前に警告させます。
- [Postman](https://www.postman.com/downloads/): APIの境界条件（異常なヘッダーや巨大なボディ）をシミュレートするテストスイートをJSONで共有しましょう。
—
4. アーキテクトの視点：チーム開発のベストプラクティス
クラッシュ分析を属人化させないためのルールを定義します。
1. 診断レポートのYAMLテンプレート化
クラッシュが発生した際、以下の情報を必ずIssueに添付するルールを策定してください。
crash-report-template.yaml
incident:
timestamp: 2023-10-27T10:00:00Z
node_version: v18.16.0
environment: production
core_dump_path: /mnt/dumps/core.12345
reproduce_steps: |
1. クライアントから特定のContent-Typeを付与したリクエストを送信
2. …
suspected_module: llhttp # 判明していれば記載
2. Core Dumpの自動収集とS3転送
CI/CDパイプライン（またはk8sのInitContainer）で、Pod終了時に `core` ファイルをS3等のストレージに退避させるスクリプトを仕込んでください。現場で発生したクラッシュを、翌朝エンジニアが安全に検証環境で再現できる状態を作ることが、チームの生産性を最も引き上げます。
最後に：道具に支配されるな
`llhttp` のような低レイヤーのバグを追うことは、Node.jsのランタイムが「ブラックボックス」ではなく、C++とJSの境界で動く「巨大な機械」であることを理解する機会です。
ツールは、あなたの思考を拡張するためのものです。`–abort-on-uncaught-exception` を恐れず、むしろ積極的に倒してログを残す。この姿勢こそが、最速で安定したシステムを構築するプロフェッショナルの条件です。今日から、あなたのチームのデバッグ文化を「推測」から「観測」へと進化させてください。