debugging — Claude Code skill: what it does, how to install
A skill for tracking down tursodb bugs: compare bytecode against SQLite, turn on trace logs, run ThreadSanitizer, replay a seed and measure stack use.
npx skills add tursodatabase/turso --skill debugging -a claude-codeWhat debugging does
This skill walks through debugging tursodb, the Rust engine behind Turso that follows SQLite behaviour. Start with bytecode: run EXPLAIN in sqlite3, then the same statement in cargo run --bin tursodb. If the plans differ, the bug is in code generation. If they match and the rows still differ, look at the VM and the storage layer.
Logging runs as RUST_LOG=none,turso_core=trace make test, writing to testing/test.log, which grows fast. Threading bugs go through stress tests under ThreadSanitizer, and that needs a nightly toolchain: rustup toolchain install nightly, then rustup override set nightly. To replay a crash, feed its seed to the simulator with RUST_LOG=limbo_sim=debug cargo run --bin limbo_sim -- -s <seed>; concurrent cases use the runner in testing/concurrent-simulator/bin/run.
Three scripts in scripts/stack/ cover stack use: frame size per function, the smallest stack that runs a SQL file, and the deepest callers under lldb. Each takes -h. Measure against a release build (cargo build --release --bin tursodb) because debug builds don't reuse stack slots and their numbers say little about what users run. WAL corruption tooling sits in scripts, with notes in references/CORRUPTION-TOOLS.md. Expect the simulator to keep the older "limbo" naming in its commands.
What it helps with
- trace why tursodb returns different rows than sqlite3 for the same query
- catch a data race with a ThreadSanitizer stress run
- replay a crash from its seed in the deterministic simulator
- find the smallest stack that survives a deeply nested expression
- inspect a corrupted WAL and check database integrity
Example prompts for the agent
- Compare the bytecode for `EXPLAIN SELECT 1 + 1;` in sqlite3 and tursodb and tell me where it diverges
- Replay this failure in the simulator with seed 1234 and explain which step breaks
- Run `scripts/stack/frame-sizes.sh` for `translate::expr::` on a release build and show the fattest frames
How to install debugging
1Skills CLI (Vercel)
npx skills add tursodatabase/turso --skill debugging -a claude-code2Manually: put the files in place
~/.claude/skills/debugging/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/debugging/
1Skills CLI (Vercel)
npx skills add tursodatabase/turso --skill debugging -a codex2Manually: put the files in place
.agents/skills/debugging/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add tursodatabase/turso --skill debugging -a cursor2Manually: put the files in place
.cursor/skills/debugging/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install tursodatabase/turso debugging2Manually: put the files in place
.github/skills/debugging/SKILL.md1Skills CLI (Vercel)
npx skills add tursodatabase/turso --skill debugging -a gemini-cli2Platform CLI
gemini skills install https://github.com/tursodatabase/turso --path .claude/skills/debuggingManually: put the files in place
.devin/skills/debugging/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add tursodatabase/turso --skill debugging -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
From the same set10
The whole set →Similar
Questions about debugging
How do I install debugging in Claude Code?
Run npx skills add tursodatabase/turso --skill debugging -a claude-code. The skill file lands in ~/.claude/skills/debugging/SKILL.md.
What does the debugging skill do?
It documents how to debug tursodb: bytecode comparison against SQLite, core trace logging, ThreadSanitizer stress tests, seeded simulation, and stack measurement with the scripts in scripts/stack/.
Do the stack measurements need a release build?
Yes. Debug builds don't reuse stack slots, so their frame sizes say little about what users run. Build with cargo build --release --bin tursodb and measure that binary.
Source text
SKILL.md · MIT
--- name: debugging description: How to debug tursodb using Bytecode comparison, logging, ThreadSanitizer, deterministic simulation, and corruption analysis tools --- # Debugging Guide ## Bytecode Comparison Flow Turso aims for SQLite compatibility. When behavior differs: ``` 1. EXPLAIN query in sqlite3 2. EXPLAIN query in tursodb 3. Compare bytecode ├─ Different → bug in code generation └─ Same but results differ → bug in VM or storage layer ``` ### Example ```bash # SQLite sqlite3 :memory: "EXPLAIN SELECT 1 + 1;" # Turso cargo run --bin tursodb :memory: "EXPLAIN SELECT 1 + 1;" ``` ## Manual Query Inspection ```bash cargo run --bin tursodb :memory: 'SELECT * FROM foo;' cargo run --bin tursodb :memory: 'EXPLAIN SELECT * FROM foo;' ``` ## Logging ```bash # Trace core during tests RUST_LOG=none,turso_core=trace make test # Output goes to testing/test.log # Warning: can be megabytes per test run ``` ## Threading Issues Use stress tests with ThreadSanitizer: ```bash rustup toolchain install nightly rustup override set nightly cargo run -Zbuild-std --target x86_64-unknown-linux-gnu \ -p turso_stress -- --vfs syscall --nr-threads 4 --nr-iterations 1000 ``` ## Deterministic Simulation Reproduce bugs with seed. Note: simulator uses legacy "limbo" naming. ```bash # Simulator RUST_LOG=limbo_sim=debug cargo run --bin limbo_sim -- -s <seed> # Whopper (concurrent DST) SEED=1234 ./testing/concurrent-simulator/bin/run ``` ## Stack Usage Parsing and translating an expression recurse once per level of nesting, so the stack frame size of those functions limits how deep an expression can be. Three scripts in `scripts/stack/` measure stack use. Use a release build (`cargo build --release --bin tursodb`): debug builds do not reuse stack slots, so their frames say little about what users run. Run each script with `-h` for all options. ```bash # Frame size of each function, read from its prologue. -c compares two binaries. scripts/stack/frame-sizes.sh 'translate::expr::' scripts/stack/frame-sizes.sh -c /tmp/tursodb-main 'translate_expr$' 'parse_expr_inner$' # Smallest stack that runs a SQL script, per binary. -S adds sqlite3. scripts/stack/min-stack.sh -S -b /tmp/tursodb-main -b target/release/tursodb deep.sql # Which functions use the stack at the deepest point (runs under lldb). scripts/stack/stack-profile.sh deep.sql ``` Functions that recurse per level should be small. Move rare and large paths into `#[inline(never)]` helpers, like SQLite's `SQLITE_NOINLINE`. ## Architecture Reference - **Parser** → AST from SQL strings - **Code generator** → bytecode from AST - **Virtual machine** → executes SQLite-compatible bytecode - **Storage layer** → B-tree operations, paging ## Corruption Debugging For WAL corruption and database integrity issues, use the corruption debug tools in [scripts](./scripts). See [references/CORRUPTION-TOOLS.md](./references/CORRUPTION-TOOLS.md) for detailed usage.
© tursodatabase · MIT · tursodatabase/turso