Headless mode never calls OpenProgram → analysis tables (funcs, names, instructions…) return 0 rows

[ogeidr]

Summary

In headless mode (--binary/--project/--project-name -q …, no --url), every analysis table returns 0 rows and db_info reports program_name=active-program with empty language_id/md5/image_base, even though Ghidra imports and analyzes the program successfully and the host binds it (the server log prints LIBGHIDRA_HEADLESS_READY … program=<name>).

Environment

• Ghidra 12.0.4 (also reproduced on 12.1), JDK 21
• Linux aarch64 (the bug is platform-independent)
• Built following install-prompt.md

Repro

ghidrasql --binary /bin/ls --project /tmp/p --project-name boot --analyze -q "SELECT COUNT(*) FROM funcs"
# -> 0
ghidrasql --binary /bin/ls --project /tmp/p --project-name boot -q "SELECT * FROM db_info"
# -> program_name = active-program, language_id / md5 empty, image_base 0

Passing --program /ls or --initial-program /ls does not help.

Root cause

src/cli/main.cpp — run_headless_live_query_local() and run_headless_live_server() hardcode:

source_opts.auto_open_program = false;

and never set source_opts.program_path. The client therefore never issues OpenProgram against the host it just launched, so the queries in src/lib/src/source_libghidra.cpp (gated on opened_program_, set only via ensure_session_open_locked() → OpenProgram) see no active program. db_info's program_name falls back to the "active-program" default (source_libghidra.cpp:1112).

The --url connect path (around main.cpp:1014) does set program_path + auto_open_program and works correctly — so headless mode is the outlier.

Suggested fix

In both headless paths, mirror the connect path: set auto_open_program and program_path from --program/--initial-program (selected_program_arg(args)), defaulting program_path to the imported binary's project path so the documented --binary … -q form works out of the box. For example:

std::string selected_program = selected_program_arg(args);
if (selected_program.empty() && !args.binary_paths.empty()) {
    std::string base = args.binary_paths.front();
    auto slash = base.find_last_of('/');
    if (slash != std::string::npos) base = base.substr(slash + 1);
    selected_program = "/" + base;
}
source_opts.auto_open_program = !selected_program.empty();
source_opts.program_path = selected_program;
source_opts.project_path = args.project;
source_opts.project_name = args.project_name;

With this change db_info populates correctly and analysis tables return rows.

[ogeidr]

Hi Elias, thanks for your work on ghidrasql. I wanted to give full disclosure about the 2 issues I've raised. I have had minimal test (just 2 failed installs in different arch, x64 and mac silicon), I am not sure the above is 100% correct but my installations of ghidrasql are now working. Also, I did use a lot of tokens to get to a root cause and solution so please excuse me if this makes 0 sense to you, I hope this helps, cheers.

[0xeb]

Thanks for this, and for being upfront about your testing setup. That helps a lot.

Got it, and I've had a first look. There's definitely something real here around db_info and the headless open path. I want to dig in properly rather than fire back something half-baked, so I'll get into it next week and report back.

If it's easy in the meantime: what does SELECT COUNT(*) FROM funcs give you on a fresh import, and which Ghidra version/arch were you on? That'll help me hit your exact case.

Thanks again for the detailed report.

[0xeb]

Thanks @ogeidr — revisiting #1 with fresh eyes, it had two distinct halves, both now addressed:

1. Analysis tables returning 0 rows — this was the kAllAddressesMax = UINT64_MAX range-end sentinel decoding to a signed -1 on the host (exactly your kAllAddressesMax (UINT64_MAX) read as -1 by Java host → range-filtered tables empty for programs with EXTERNAL blocks #2 analysis). It bites programs with EXTERNAL / low-offset address spaces — e.g. dynamically-linked binaries on Linux — which is likely what you hit. Fixed in Fix range-filtered tables returning 0 rows (#2, #3, #6) #7 (client) + host: treat unbounded range-end as Long.MAX_VALUE (ghidrasql #2/#3/#6) libghidra#16 (host), both merged.

2. db_info placeholders (program_name=active-program, empty language_id, image_base=0) — fixed in fix(db_info): report real program metadata for the active program (#1) #9: db_info now resolves the active program from the revision and opens it to report real metadata (program_name, language_id, compiler_spec, image_base). md5/sha256 stay empty for now — the host's OpenProgram response doesn't carry them, so that's a separate host-side follow-up.

Once #9 lands, both halves are resolved. Closing then — thanks for the careful original report.

[0xeb]

Both halves resolved: range-sentinel bug (#7 / 0xeb/libghidra#16) and db_info metadata (#9, merged). Thanks again @ogeidr.

[ogeidr]

Thanks for your work on ghidrasql and getting this fixed, cheers.