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: Example Manual Query Inspection Logging Threading Issues Use stress tests with ThreadSanitizer: Deterministic Simulation Reproduce bugs with seed. Note: simulator uses legacy "limbo" naming. 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. 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.

debugging