detect_changes crashes Node/WSL with @ladybugdb/core 0.17.1 native binding

[zhYou]

Summary

gitnexus detect_changes --repo <repo> crashed the Node process hard enough for WSL to write a core dump.

This looks related to the LadybugDB native FTS delete/update path used by @ladybugdb/core@0.17.1. It may be the same class of issue as LadybugDB/ladybug#588, fixed upstream by LadybugDB/ladybug#592, but I cannot prove it is the exact same minimal trigger because I do not have a symbolized native backtrace yet.

Environment

OS: WSL/Linux x64
Node: v24.16.0
GitNexus: 1.6.7
@ladybugdb/core: 0.17.1
@ladybugdb/core native binding: lbugjs.node
lbugjs.node build id: aa1932752009121f06121daff0baad51bae09459

The crash happened from an npx cache install:

/tmp/npm-cache/_npx/5e786f48223a616c/node_modules/gitnexus/package.json

That package resolves:

{
  "gitnexus": "1.6.7",
  "@ladybugdb/core": "0.17.1"
}

Command

The WSL core file records the process as:

node /tmp/npm-cache/_npx/5e786f48223a616c/node_modules/.bin/gitnexus detect_changes --repo <repo>

The original repo path was a private Java monorepo, so I am redacting it here as <repo>.

Observed Behavior

detect_changes crashes the process at the native layer. WSL produced a core dump:

ELF 64-bit LSB core file, x86-64, from 'node /tmp/npm-cache/_npx/5e786f48223a616c/node_modules/.bin/gitnexus detect_cha'

The dump shows the process loaded native modules including:

/tmp/npm-cache/_npx/5e786f48223a616c/node_modules/@ladybugdb/core/lbugjs.node
/tmp/npm-cache/_npx/5e786f48223a616c/node_modules/tree-sitter*/prebuilds/linux-x64/*.node

The dump is about 12 GB, so I cannot attach it directly to the issue. I can provide more targeted output if there is a recommended way to symbolicate or extract the relevant native stack.

Why I think this is related to LadybugDB FTS delete

I found a very similar upstream issue:

• Bug: FTS delete can SIGBUS when runtime tokenization diverges from create-time indexing LadybugDB/ladybug#588: "Bug: FTS delete can SIGBUS when runtime tokenization diverges from create-time indexing"
• Update extension submodule for fts-bug LadybugDB/ladybug#592: "Update extension submodule for fts-bug"

LadybugDB #588 is also on v0.17.1 and describes a native crash in the FTS delete maintenance path:

FTSIndex::deleteFromTermsTable
FTSIndex::delete_
NodeTable::delete_
SingleLabelNodeDeleteExecutor::delete_

The current GitNexus stable package still resolves @ladybugdb/core@0.17.1. @ladybugdb/core does not appear to have a stable npm release newer than 0.17.1 at the time of this report, so gitnexus@1.6.7 does not appear to include the upstream LadybugDB fix yet.

Expected Behavior

detect_changes should not be able to crash the Node process through the native database binding. Ideally it should either:

• use a LadybugDB build that contains the upstream FTS delete fix,
• avoid the unsafe FTS delete/update path during detect_changes,
• detect the risky @ladybugdb/core@0.17.1 version and warn/fallback,
• or fail gracefully with a diagnostic message instead of crashing.

Diagnostic Assistance

This report was prepared with help from OpenAI Codex in a local terminal session. Codex inspected the npx cache package metadata, WSL core file metadata/strings, installed package versions, and related GitHub issues/PRs. The affected user reproduced the crash; Codex only assisted with collecting and summarizing diagnostics.

No credentials, tokens, or private repository contents are included in this report. The private repository path has been redacted as <repo>.

Notes

I am reporting this to GitNexus first because the user-visible entry point is gitnexus detect_changes, and GitNexus controls the @ladybugdb/core dependency range and fallback behavior. If you prefer a minimal LadybugDB repro, I can try to extract more data from the .gitnexus database or core dump, but I would prefer guidance before rerunning the command because it crashes WSL on this machine.