LiteSVM 0.13.0 Adds GDB Debugger Support for Solana Program Testing

LiteSVM, the in-process Solana Virtual Machine library for Rust unit testing, released version 0.13.0 on June 19 with its most significant developer experience addition to date: a GDB remote debugger stub that lets developers attach a standard debugger to a running Solana program during a test run.

LiteSVM: In-Process Solana Testing Without a Validator

LiteSVM is a Rust crate that runs the full Solana runtime (account model, compute budget, syscalls, cross-program invocations) inside a test process, without spinning up a validator node. The library is designed as a faster, lighter alternative to solana-program-test and solana-test-validator. Because it compiles and executes in-process, test cycles that would take seconds against a local validator typically complete in milliseconds.

The library is maintained by Aursen, who announced the 0.13.0 release on June 19.

GDB Remote Stub for SBPF Program Debugging

Until now, debugging a misbehaving Solana program in a unit test meant reading msg!() log output, a workflow that collapses to guesswork when the bug is in a deep call path or surfaces only under specific account state. Native debugger support did not exist for in-process SVM testing.

Version 0.13.0 adds an SBPF (Solana Bytecode Format Program) debugger backed by a GDB remote stub. When the feature is enabled, LiteSVM opens a TCP port (configured via the SBF_DEBUG_PORT environment variable) and speaks the GDB remote serial protocol. Developers can connect any GDB-compatible client, set breakpoints, inspect registers, step through instructions, and resume execution across cross-program invocation boundaries.

A trace filtering system, built on a nom-based expression parser, controls which invocations trigger the debugger and which trace events are collected. Filters can match by transaction signature (txsig) or program ID, with support for ==, !=, ||, && operators and parenthesized grouping. This makes it practical to isolate a single program or transaction in a test suite that exercises many.

The implementation also writes a program_ids.map file that maps program addresses to ELF SHA-256 hashes, using the same format as the mollusk testing framework. This file enables symbol resolution in a connected debugger.

Agave 4.0 Alignment Keeps Tests Current with Upcoming Validator Changes

The release bumps LiteSVM's internal runtime to track Agave 4.0, the next major version of the Anza validator client. The update (PR #322) pulls in the updated mainnet feature set and corrects outdated feature activation dates that had accumulated in prior releases. A maintenance script added in PR #357 automates future mainnet feature syncs, reducing the manual work needed to keep LiteSVM current with network upgrades.

Keeping test environments aligned with the validator client the network runs means that programs passing LiteSVM tests are more likely to behave correctly on mainnet after Agave 4.0 activates.

SPL Token 2022 v11.0.0 and Stake Program Fixes

PR #358 updates LiteSVM's bundled Token-2022 program to version 11.0.0. Programs that use Token-2022 extensions can now test against the current program version without workarounds.

The release also fixes stake program panics that occurred when testing against mainnet-forked state (PR #346), which required updating the bundled stake ELF from v1.0.1 to v5.0.0 to handle the current V4 vote account format.

LiteSVM 0.13.0 is available on crates.io. The Node.js wrapper (node-litesvm with Kit) is at version 1.2.0, released alongside the Rust crate.