tursodatabase / tursodatabase/libsql
Embedded replica (or offline sync) db stack overflows on Windows
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 17.2k
- Forks
- 531
- Avg merge
- 1h 12m
- Merged PRs (30d)
- 1
Description
A user is trying to make ER on Windows but unfortunately it stack overflows. This is possibly related to the bugs: https://github.com/tursodatabase/libsql/issues/1349 and https://github.com/tursodatabase/libsql/issues/1051
Full reproducer is here: https://github.com/kunjee17/dx_todo
dx serve --platform desktop
# through brew
brew install cargo-binstall
# or from source
cargo install cargo-binstall
cargo binstall dioxus-cli
cargo install
Even a simple example like following is also failing:
let db = Builder::new_remote_replica(path, url, token).build().await.unwrap();
let conn = db.connect().unwrap();
// Create table if it doesn't exist
let create_table = conn.execute(
"CREATE TABLE IF NOT EXISTS users (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT NOT NULL,
email TEXT NOT NULL UNIQUE
)",
(),
)
.await
.unwrap();
println!("Created table: {}", create_table);
Increasing the stack size to 800MB also did not work:
# 64 bit MSVC
[target.x86_64-pc-windows-msvc]
rustflags = [
"-C", "link-arg=/STACK:800000000"
]
# 64 bit Mingw
[target.x86_64-pc-windows-gnu]
rustflags = [
"-C", "link-arg=-Wl,--stack,800000000"
]
Here are the logs:
warning: unused manifest key: target.x86_64-pc-windows-gnu.rustflags
warning: unused manifest key: target.x86_64-pc-windows-msvc.rustflags
Blocking waiting for file lock on package cache
Blocking waiting for file lock on package cache
Blocking waiting for file lock on package cache
Blocking waiting for file lock on build directory
Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.59s
Running `target\debug\todo.exe`
2025-05-22T05:22:38.656484Z DEBUG hyper::client::connect::dns: resolving host="<db-name-redacted>.aws-ap-south-1.turso.io"
2025-05-22T05:22:38.666319Z DEBUG hyper::client::connect::dns: resolving host="<db-name-redacted>.aws-ap-south-1.turso.io"
2025-05-22T05:22:38.679580Z DEBUG hyper::client::connect::http: connecting to 13.200.53.177:443
2025-05-22T05:22:38.680493Z DEBUG hyper::client::connect::http: connecting to 13.200.53.177:443
2025-05-22T05:22:38.703463Z DEBUG hyper::client::connect::http: connected to 13.200.53.177:443
2025-05-22T05:22:38.704924Z DEBUG hyper::client::connect::http: connected to 13.200.53.177:443
2025-05-22T05:22:38.816853Z DEBUG hyper::proto::h1::io: flushed 380 bytes
2025-05-22T05:22:38.889709Z DEBUG hyper::proto::h1::io: parsed 2 headers
2025-05-22T05:22:38.890100Z DEBUG hyper::proto::h1::conn: incoming body is empty
2025-05-22T05:22:38.890685Z DEBUG hyper::client::pool: pooling idle connection for ("https", <db-name-redacted>.aws-ap-south-1.turso.io)
2025-05-22T05:22:38.893290Z DEBUG libsql::sync: read sync metadata for db_path="C:\\Users\\<name-redacted>\\AppData\\Roaming\\FuzzyCloud\\todo\\data\\local.db", metadata=MetadataJson { hash: 3278479626, version: 0, durable_frame_num: 0, generation: 1 }
2025-05-22T05:22:38.894499Z DEBUG hyper::client::connect::dns: resolving host="<db-name-redacted>.aws-ap-south-1.turso.io"
2025-05-22T05:22:38.895535Z DEBUG hyper::client::connect::http: connecting to 13.200.53.177:443
2025-05-22T05:22:38.929952Z DEBUG hyper::client::connect::http: connected to 13.200.53.177:443
2025-05-22T05:22:38.988262Z DEBUG hyper::proto::h1::io: flushed 374 bytes
2025-05-22T05:22:39.042660Z DEBUG hyper::proto::h1::io: parsed 3 headers
2025-05-22T05:22:39.042914Z DEBUG hyper::proto::h1::conn: incoming body is content-length (25 bytes)
2025-05-22T05:22:39.043262Z DEBUG hyper::proto::h1::conn: incoming body completed
2025-05-22T05:22:39.043796Z DEBUG hyper::client::pool: pooling idle connection for ("https", <db-name-redacted>.aws-ap-south-1.turso.io)
thread 'main' has overflowed its stack
error: process didn't exit successfully: `target\debug\todo.exe` (exit code: 0xc00000fd, STATUS_STACK_OVERFLOW)
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 by reproducing the failure on Windows with the dx_todo project and the minimal Rust example using Builder::new_remote_replica, connect, and execute. Inspect embedded replica initialization after the sync metadata is read, and compare the behavior with the related issues 1349 and 1051. Done means the example creates the database table without a STATUS_STACK_OVERFLOW failure.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust, sqlite
- Domain
- databases, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 32/100