René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"sqlite: reentrancy into a running statement from a user-defined function is unguarded","articleBody":"### Version\n\n`main` (verified on `2b350bb8e42`)\n\n### Platform\n\n```text\nDarwin 25.6.0 arm64 (macOS); not platform-specific\n```\n\n### Subsystem\n\nsqlite\n\n### What steps will reproduce the bug?\n\n#64743 added a database-level callback-depth guard, so `db.close()` from inside a user-defined function now correctly throws `ERR_INVALID_STATE` instead of finalizing a statement mid-`sqlite3_step()` (that was #63180, now fixed). The guard is per-*database*, so it does not cover a callback reentering the specific statement that invoked it. SQLite forbids calling `sqlite3_step()` / `sqlite3_reset()` / `sqlite3_finalize()` on a statement while that statement's own callback is on the stack.\n\nTwo cases:\n\n**1. Reentrant `iter.next()` silently advances the iterator being consumed.**\n\n```js\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();\n\nlet iter;\ndb.function('reenter', () => {\n  iter.next();   // reenters the statement currently being stepped\n  return 0;\n});\n\niter = db.prepare('SELECT reenter() FROM t').iterate();\nconsole.log(iter.next());\n```\n\n**2. Recursive `stmt.get()` on the running statement.**\n\n```js\nconst { DatabaseSync } = require('node:sqlite');\nconst db = new DatabaseSync(':memory:');\nlet stmt;\ndb.function('x', () => stmt.get());\nstmt = db.prepare('SELECT x()');\nstmt.get();\n```\n\n### How often does it reproduce? Is there a required condition?\n\nAlways. The callback must reenter the same statement object that is currently executing.\n\n### What is the expected behavior? Why is that the expected behavior?\n\nBoth should throw `ERR_INVALID_STATE`, consistent with how #64743 handles `db.close()` from a callback. Cross-statement use from a callback (the common \"lookup\" pattern — preparing or stepping a *different* statement) should keep working; only reentry into the running statement is forbidden by the C API.\n\n### What do you see instead?\n\nCase 1: no error. The reentrant `next()` consumes rows from the same VM, so the outer iteration silently skips them:\n\n```\nreentrant next() SUCCEEDED\nreentrant next() SUCCEEDED\nfirst: {\"done\":false,\"value\":{\"reenter()\":0}}\n```\n\nCase 2: `Maximum call stack size exceeded` — a V8 stack overflow rather than a SQLite-level error, so the actual constraint is never reported.\n\nNeither crashes, so this is a correctness issue rather than memory safety.\n\n### Additional information\n\nThe closed #63183 contained a per-statement `IsStepping()` RAII flag (`MarkStepping()` around every `sqlite3_step` caller, with JS-callable step/reset/finalize checking it) that addresses exactly this, plus regression tests for both cases. That PR was closed in favor of #64743, which covers only the database-level `close()` path, so the per-statement piece is currently unowned. It may be worth salvaging from that branch.\n","author":{"url":"https://github.com/TrevorBurnham","@type":"Person","name":"TrevorBurnham"},"datePublished":"2026-08-07T12:23:41Z","url":"https://github.com/nodejs/node/issues/65102"}