René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"sqlite: GC of an unreferenced session frees memory SQLite is still using","articleBody":"### Version\n\n`main` (21f0f2786f0)\n\n### Platform\n\n```text\nDarwin 25.6.0 Darwin Kernel Version 25.6.0: Fri Jul 31 19:19:08 PDT 2026; root:xnu-12377.161.14~5/RELEASE_ARM64_T6050 arm64\n```\n\n### Subsystem\n\nsqlite\n\n### What steps will reproduce the bug?\n\nLet a session become unreachable from JavaScript, then let GC run while SQLite is inside its pre-update hook. Run with `--expose-gc`:\n\n```js\nimport { DatabaseSync, constants } from 'node:sqlite';\n\nconst db = new DatabaseSync(':memory:');\ndb.exec('CREATE TABLE t(a PRIMARY KEY)');\ndb.createSession(); // return value dropped: no JS reference kept\n\nlet once = true;\ndb.setAuthorizer((action, p1) => {\n  if (action === constants.SQLITE_PRAGMA && p1 === 'table_xinfo' && once) {\n    once = false;\n    globalThis.gc();\n    globalThis.gc();\n  }\n  return constants.SQLITE_OK;\n});\n\ndb.exec('INSERT INTO t VALUES (1)');\nconsole.log('survived');\n```\n\nA `'sqlite.db.query'` diagnostics-channel subscriber calling `gc()` in place of the authorizer crashes the same way.\n\n### How often does it reproduce? Is there a required condition?\n\nI get exit 139 on every run.\n\n### What is the expected behavior? Why is that the expected behavior?\n\nThe write should complete and the session should still record the change. A session that JavaScript can no longer reach is still registered on the connection and still accumulating changes, so collecting it is observable in two ways beyond the crash: the changeset silently stops recording, and `sqlite3session_delete()` runs at an arbitrary point.\n\n### What do you see instead?\n\n`EXC_BAD_ACCESS` in `sqlite3StrICmp`, from the `sqlite3_strnicmp(zDb, pSession->zDb, nDb + 1)` comparison in `xPreUpdate` (`deps/sqlite/sqlite3.c:235727`) reading a freed `sqlite3_session`.\n\n### Additional information\n\n`Session` calls `MakeWeak()` (`src/node_sqlite.cc:4271`) and `DatabaseSync::sessions_` holds raw `Session*` (`src/node_sqlite.h:340`), so nothing keeps a session alive once JS drops it. SQLite's pre-update hook walks the connection's session list and runs `PRAGMA table_xinfo` from inside that walk, which reaches JavaScript and gives GC a chance to run while the walk still holds pointers into the session being visited.\n\nThis is the same window as #65428, but a different trigger.\n\nThe obvious fix of making `sessions_` hold `BaseObjectPtr\u003cSession>` does not work on its own: `Session::database_` is already a `BaseObjectPtr\u003cDatabaseSync>`, so that creates a cycle that leaks both objects for the life of the process. Options that seem workable: hold strong refs to the attached sessions only for the duration of SQLite calls that can fire the pre-update hook, or keep sessions strongly held by the database and make the back-reference weak.\n","author":{"url":"https://github.com/TrevorBurnham","@type":"Person","name":"TrevorBurnham"},"datePublished":"2026-08-21T17:01:29Z","url":"https://github.com/nodejs/node/issues/65460"}