tursodatabase / tursodatabase/libsql
STATUS_ACCESS_VIOLATION (0xC0000005) on concurrent Builder::new_local(...).build() in one process (Windows, 0.9.30)
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 17.2k
- Forks
- 531
- Avg merge
- 1h 12m
- Merged PRs (30d)
- 1
Description
Summary
Opening ~32 or more distinct local (file-backed) databases concurrently from one process
crashes the process with STATUS_ACCESS_VIOLATION (0xC0000005) at a rate of roughly
15–40%. There is no panic, no libsql::Error, and no SQLite error code — the process is
terminated by the OS.
The same number of opens performed sequentially in the same process never faults. Holding
every handle alive until all tasks complete still faults, so this is a race in open, not in
teardown or in the drop path.
Environment
libsql |
0.9.30 (also present on 0.6.0; upgrading did not change the rate) |
| OS | Windows 11 Pro 26100 (x86_64) |
| Runtime | tokio 1.x, multi-thread runtime |
| Profile | --release (also reproduces in debug) |
| Databases | local file-backed, one distinct file per task, on local NTFS |
Reproduction
Cargo.toml:
[dependencies]
libsql = "0.9.30"
tokio = { version = "1", features = ["rt-multi-thread", "macros"] }
tempfile = "3"
src/main.rs:
use std::env;
use std::path::PathBuf;
async fn one(path: PathBuf) {
let db = libsql::Builder::new_local(&path).build().await.expect("build");
let conn = db.connect().expect("connect");
conn.execute("CREATE TABLE IF NOT EXISTS t (id INTEGER PRIMARY KEY, v TEXT)", ())
.await
.expect("create");
conn.execute("INSERT INTO t (v) VALUES ('x')", ()).await.expect("insert");
drop(conn);
drop(db);
}
#[tokio::main]
async fn main() {
let args: Vec<String> = env::args().collect();
let mode = args.get(1).map(String::as_str).unwrap_or("churn");
let n: usize = args.get(2).and_then(|s| s.parse().ok()).unwrap_or(500);
let dir = tempfile::tempdir().expect("tempdir");
match mode {
// One at a time.
"churn" => {
for i in 0..n {
one(dir.path().join(format!("db{i}.sqlite"))).await;
}
}
// All at once.
"concurrent" => {
let mut handles = Vec::with_capacity(n);
for i in 0..n {
handles.push(tokio::spawn(one(dir.path().join(format!("db{i}.sqlite")))));
}
for h in handles { h.await.expect("task"); }
}
// All at once, and nothing is dropped until every task has finished.
"hold" => {
let mut handles = Vec::with_capacity(n);
for i in 0..n {
let p = dir.path().join(format!("db{i}.sqlite"));
handles.push(tokio::spawn(async move {
let db = libsql::Builder::new_local(&p).build().await.expect("build");
let conn = db.connect().expect("connect");
conn.execute("CREATE TABLE IF NOT EXISTS t (id INTEGER PRIMARY KEY)", ())
.await
.expect("create");
(db, conn)
}));
}
let mut kept = Vec::with_capacity(n);
for h in handles { kept.push(h.await.expect("task")); }
drop(kept);
}
other => panic!("unknown mode {other}"),
}
println!("{mode} {n}: ok");
}
Run each mode repeatedly and check the exit code (the fault aborts the process, so stdout
is not a reliable signal):
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the Rust reproduction in src/main.rs and run the sequential, concurrent, and hold modes repeatedly on Windows, checking process exit codes rather than stdout. Trace the concurrent Builder::new_local(...).build() path in the libsql and SQLite database-opening code. Done means the concurrent distinct local-database opens no longer terminate the process and the reproduction completes successfully.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust, sqlite
- Domain
- backend, databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100