[mostafa-yassine]

Context

This fork is embedded in a mobile app that uses libsql remote replicas. The app drops its libsql::Connection and libsql::Database and builds new ones every time it refreshes its auth token.

Problem

Dropping a local connection closes the sqlite3 handle twice.

1. LibsqlConnection::drop (libsql/src/local/impls.rs:108) calls self.conn.disconnect(). This calls sqlite3_close_v2(self.raw) and frees the handle.
2. The inner field conn: local::Connection is then dropped. Connection::drop (libsql/src/local/connection.rs:38) calls disconnect() again. self.raw still holds the freed pointer and drop_ref is still unique, so sqlite3_close_v2 runs on freed memory.

Upstream tracks this as tursodatabase#2251. Valgrind shows one Invalid read of size 1 in sqlite3SafetyCheckSickOrOk per connection.

In production this shows up as a native SIGSEGV on Android. The symbolicated stack is:

sqlite3SafetyCheckSickOrOk          (sqlite3.c:36835, reads db->eOpenState)
sqlite3Close
drop_in_place<libsql::local::connection::Connection>
drop_in_place<libsql::replication::connection::RemoteConnection>
<app code that reconnects after a token refresh>

The crash is intermittent because the allocator usually keeps the freed page mapped. It faults only when the page was released or reused, so it is rare per device and common across a fleet.

Solution

Cherry-pick upstream tursodatabase#2261 (4e06af572d): disconnect() sets self.raw to null after sqlite3_close_v2. The second call passes a null handle, which sqlite3_close_v2 accepts as a no-op.

This PR adds a unit test, local::connection::tests::disconnect_is_idempotent, that fails on the base branch and passes with the fix, and a second test that drops through the public API so a sanitizer run exercises both Drop impls.

This PR does not change the LibsqlConnection and Connection Drop impls. Both still call disconnect(). The second call is now a no-op.

Testing

Two unit tests in local::connection::tests:

• disconnect_is_idempotent calls disconnect() twice and checks raw is null after each call. Fails on the base branch (assertion failed: conn.raw.is_null()), passes with the fix.
• dropping_public_connection_closes_once builds a local database through Builder::new_local, connects, runs one statement, and drops, 20 times, so both Drop impls run. It passes on any allocator. Under a guard allocator every freed page is unmapped, so the second close faults if the handle is not nulled:

BIN=$(cargo test -p libsql --features replication --lib --no-run 2>&1 | grep -o 'target/debug/deps/libsql-[a-z0-9]*')
DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib $BIN dropping_public_connection_closes_once   # macOS
valgrind $BIN dropping_public_connection_closes_once                                           # Linux

Base branch: SIGSEGV, exit 139. lldb:

frame #0: sqlite3SafetyCheckSickOrOk at sqlite3.c:36835:20   eOpenState = db->eOpenState
frame #1: sqlite3Close at sqlite3.c:182133
frame #2: sqlite3_close_v2 at sqlite3.c:182234
frame #3: libsql::local::connection::Connection::disconnect at connection.rs:111
frame #4: <Connection as Drop>::drop at connection.rs:40              second close
frame #5: drop_glue::<libsql::local::connection::Connection>
frame #6: drop_glue::<libsql::local::impls::LibsqlConnection>         first close ran in its Drop
frame #9: Arc<dyn Conn>::drop_slow

This is the production stack frame for frame. With this PR: 1 passed, exit 0.

Checks. cargo check -p libsql --features replication and cargo fmt -p libsql -- --check pass.

Follow-up. Cut a libsql-rs-v0.9.30+shopify.N tag so consumers can bump.

Related issues

• tursodatabase/libsql#2251
• tursodatabase/libsql#2261