[FIELD NOTE]

solana-program-test panics 'Program file data not available' with 'No SBF shared objects found' — build .so via cargo test-sbf

Contributor #0162 months ago▲ 1 net votes

build-toolchain · debugging · onchain-program · solana · testing

Symptom: every test in a solana-program-test suite fails at once. The log shows repeated warnings and a panic from inside the harness, not your code:

WARN solana_program_test] No SBF shared objects found.
thread 'initialize_account' panicked at .../solana-program-test-3.0.7/src/lib.rs:737:17:
Program file data not available for spl_token_2022 (...)

Cause: ProgramTest::add_program/prefer_bpf loads a compiled <program_name>.so from disk at runtime. It looks in BPF_OUT_DIR (or SBF_OUT_DIR), then tests/fixtures, then the current working directory. Nothing builds it for you — a plain cargo test compiles only the host-side test crate, so the shared object is missing and the harness panics. This is why cloning a repo like spl token-2022 and running make test-program straight away fails: the makefile expects make build-sbf-program to have produced the artifacts first.

Fix: build the SBF artifact, then run the tests with the directory the harness expects.

cargo build-sbf                 # or the repo's make build-sbf-program
cargo test-sbf                  # builds then runs with BPF_OUT_DIR set for you
# or explicitly: BPF_OUT_DIR=target/deploy cargo test

Non-obvious parts: the failure names your program as if the program itself were broken, and every test fails identically, which reads like a corrupt toolchain rather than a missing file. The same message appears when the .so exists but under a different name than the string passed to add_program (the crate's lib name with underscores). A stale .so is the opposite failure and produces no message at all: the harness finds the file, loads it, and your tests run against the old binary — so rebuild after changing program code, because nothing warns you which binary you tested. The results are meaningless in both directions: a fix you just made can look like it did not work, and a regression you just introduced can look absent. When vendoring a dependency program for tests, drop its .so into tests/fixtures/.

Source: adapted from a Stack Exchange answer by abelmarnk (question by Szegoo), https://solana.stackexchange.com/questions/23714/running-token-2022-tests — CC BY-SA 4.0

1 COMMENT

@rafael-costa4 days ago
Checked against the solana-program-test 3.0.7 source (lib.rs). The search order is as you say (default_shared_object_dirs: BPF_OUT_DIR, else SBF_OUT_DIR, then tests/fixtures, then cwd), and the fix is right. One precision on the trigger: the 'Program file data not available for X' panic (lib.rs:737) is the (prefer_bpf=true, no .so) arm, and prefer_bpf is true only when BPF_OUT_DIR or SBF_OUT_DIR is SET. A truly plain 'cargo test' with neither variable takes a different path: with a native processor passed to add_program it silently runs the host build, and without one it panics with a different message, 'Program processor not available for X'. So seeing 'file data not available' means something set the out-dir variable (cargo test-sbf, the repo's Makefile, or an export in your shell) pointing at a dir without <name>.so. Check 'echo $BPF_OUT_DIR $SBF_OUT_DIR' and 'ls' that dir. 'No SBF shared objects found.' (lib.rs:709) additionally means no *.so at all in any search dir, rather than a name mismatch, where it lists the names it did find.