René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"node:sqlite segfaults when db.close() is called from a user-defined function callback during query execution","articleBody":"### Version\n\nall current versions (tested v22.22.2, v24.15.0, v25.9.0, and v26.1.0)\n\n### Platform\n\n```text\nAll platforms are impacted.\n\n(but because you asked:)\n\n$ uname -a\nLinux swift 6.17.0-23-generic #23~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Apr 14 16:11:48 UTC 2 x86_64 x86_64 x86_64 GNU/Linux\n$ cat /etc/lsb-release \nDISTRIB_ID=Ubuntu\nDISTRIB_RELEASE=24.04\nDISTRIB_CODENAME=noble\nDISTRIB_DESCRIPTION=\"Ubuntu 24.04.4 LTS\"\n```\n\n### Subsystem\n\nsqlite\n\n### What steps will reproduce the bug?\n\nThere are **two distinct crash classes**, both triggered by `db.close()` from inside a user-defined function callback. The original `.all()` repro and the `.run()` repro below are verified to segfault on `main`; the other Class A variants are expected to segfault by code inspection — they all funnel through the same `StatementExecutionHelper` step sites.\n\n**Class A — Statement VM freed mid-step.** The original report; affects every StatementSync execution path that runs `sqlite3_step`:\n\n```js\n// .all() — segfaults\nconst { DatabaseSync } = require(\"node:sqlite\");\nconst db = new DatabaseSync(\":memory:\");\ndb.exec(\"CREATE TABLE t (id INTEGER PRIMARY KEY, v INTEGER)\");\ndb.prepare(\"INSERT INTO t VALUES (1, 10)\").run();\ndb.prepare(\"INSERT INTO t VALUES (2, 20)\").run();\ndb.function(\"close_db\", (x) => { try { db.close(); } catch {} return x; });\ndb.prepare(\"SELECT close_db(v) FROM t\").all();\n```\n\n```js\n// .get() — same crash\ndb.prepare(\"SELECT close_db(v) FROM t\").get();\n```\n\n```js\n// iterator — same crash\nconst iter = db.prepare(\"SELECT close_db(v) FROM t\").iterate();\niter.next();\n```\n\n```js\n// SQL tag store .all() / .get() — same crash\nconst sql = db.createTagStore(4);\nsql.all`SELECT close_db(v) FROM t`;\n```\n\n**Class B — `db->Connection()` null deref after step.** Distinct crash path, only surfaces in `.run()` (and the SQL-tag `.run()`), even after Class A is fixed by deferring finalize. After `sqlite3_step` returns, `StatementExecutionHelper::Run` reads `sqlite3_last_insert_rowid(db->Connection())` and `sqlite3_changes64(db->Connection())`. The reentrant `db.close()` set `db->connection_ = nullptr` before step returned, and the bundled SQLite is built without `SQLITE_ENABLE_API_ARMOR`, so passing `NULL` to those calls is a null-pointer deref:\n\n```js\n// .run() — segfaults via the connection-null path\nconst { DatabaseSync } = require(\"node:sqlite\");\nconst db = new DatabaseSync(\":memory:\");\ndb.exec(\"CREATE TABLE t (id INTEGER PRIMARY KEY, v INTEGER)\");\ndb.function(\"close_db\", (x) => { try { db.close(); } catch {} return x; });\ndb.prepare(\"INSERT INTO t SELECT close_db(1), close_db(2)\").run();\n```\n\n```js\n// SQL tag store .run() — same crash\nconst sql = db.createTagStore(4);\nsql.run`INSERT INTO t SELECT close_db(${1}), close_db(${2})`;\n```\n\n### How often does it reproduce? Is there a required condition?\n\n100%.\n\nThe user-function callback must call db.close() while the outer sqlite3_step is still on the call stack.\n\n### What is the expected behavior? Why is that the expected behavior?\n\nEither a clean error (\"database closed during query\" / SQLITE_INTERRUPT-style) or graceful completion of the in-flight statement followed by close. Process must not crash.\n\n### What do you see instead?\n\nSegmentation fault (core dumped), exit code 139 on linux\n\n### Additional information\n\n(full disclosure: produced with assistance from claude) ","author":{"url":"https://github.com/mceachen","@type":"Person","name":"mceachen"},"datePublished":"2026-05-08T00:27:57Z","url":"https://github.com/nodejs/node/issues/63180"}