Web Storage Maybe leaks SQLite connections when database initialization fails

[Archkon]

Version

latest main branch

Platform

Subsystem

No response

What steps will reproduce the bug?

use broken db or many of condition

How often does it reproduce? Is there a required condition?

Every failed init

What is the expected behavior? Why is that the expected behavior?

A connection created by sqlite3_open() should be closed whenever database initialization fails. Repeated failed Web Storage operations should not increase the number of open file descriptors.

What do you see instead?

The number of open descriptors increases with every failed initialization attempt.

Additional information

No response

[JosephDoUrden]

Confirmed on current main, and it's not a maybe. 50 failed inits leak exactly 50 fds:

// node --localstorage-file=./corrupt.db  (any non-sqlite file)
const fds = () => require("fs").readdirSync("/dev/fd").length;
const before = fds();
for (let i = 0; i < 50; i++) { try { localStorage.length; } catch {} }
console.log(before, "->", fds());  // 12 -> 62

Root cause is in Storage::Open in src/node_webstorage.cc. sqlite3_open allocates a handle even when it fails, and the handle is only adopted into the RAII conn_unique_ptr on the last line of the function. Every early error return between the open and that line leaves the connection unclosed. And since db_ never gets set on failure, the next localStorage operation retries the whole init and leaks another one, which is the fd growth you measured.

There's a second bug a few lines down. The sqlite3_prepare_v2 return value gets overwritten before it's checked by what looks like a copy-pasted second sqlite3_exec of init_sql_v0, so prepare failures are masked and the init SQL runs twice on every open.

Happy to send a PR. The fix is small, adopt the handle into the unique_ptr right after sqlite3_open and drop the stray exec.