`funcs`, `strings`, `names`, `blocks`, `xrefs`, `instructions`, `imports`, `exports` return 0 rows with LibGhidraHost 12.1.2

[Grazfather]

disclosure: Claude wrote this for me.

Summary

When connecting ghidrasql 0.0.2 to LibGhidraHost extension version 12.1.2 (Ghidra 12.1.2), several core virtual tables return 0 rows despite a fully analyzed program being loaded. Decompiler-backed tables and a subset of metadata tables work correctly.

Environment

• ghidrasql: 0.0.2
• LibGhidraHost extension: 12.1.2 (createdOn 2/20/2026)
• Ghidra: 12.1.2
• Platform: macOS (Darwin 24.6.0, arm64)
• Binary under analysis: statically-linked MIPS BE 32-bit ELF (fully analyzed, ~80 functions)

Reproduction

# Launch from Ghidra GUI with LibGhidraHost running on port 18080
env -u GHIDRA_INSTALL_DIR ghidrasql --url http://127.0.0.1:18080 \
  -q "SELECT COUNT(*) AS n FROM funcs;"
# Returns: 0

# Also reproduces in headless mode:
ghidrasql --ghidra /path/to/ghidra_12.1.2_PUBLIC \
  --project ./proj --project-name test \
  --binary sample.elf \
  -q "SELECT COUNT(*) AS n FROM funcs;"
# Returns: 0 (after full analysis completes)

Tables affected

Table	Rows returned	Expected
funcs	0	~80
strings	0	>0
names	0	>0
blocks	0	>0
xrefs	0	>0
instructions	0	>0
imports	0	>0
exports	0	>0

Tables that work correctly

Table	Rows returned
segments	17
memory_blocks	17
types	22
pseudocode (with WHERE func_addr = X)	1
decomp_lvars (with WHERE func_addr = X)	correct
decomp_tokens (with WHERE func_addr = X)	correct
comments	correct

Functions that work correctly

• decompile(addr) — returns full pseudocode
• save_database() — commits mutations
• cache_stats() — shows valid freshness tokens and program path
• program_revision() — returns correct revision number

Additional observations

• db_info returns placeholder values for program_name and program_path ("active-program"), and empty strings for language_id, compiler_spec, md5, sha256. However cache_stats() shows correct program_id and program_path in the freshness token.
• UPDATE funcs SET name = '...' WHERE address = 0xX succeeds (returns success: true) and the rename is reflected in subsequent decompile() output, despite SELECT on funcs returning 0 rows.
• The issue reproduces in both GUI-hosted (--url) and headless (--ghidra) modes.
• Creating a fresh project with --fresh --binary and letting full analysis complete does not resolve the issue.

[0xeb]

Thanks for the thorough write-up — your "working vs broken" table is the tell: only the range-scanned tables are affected, because they all share the buggy UINT64_MAX → -1 → getMaxAddress() range-end fallback (#2). It isn't a version mismatch; decompile()/pseudocode work because they look up a specific address rather than scanning a range.

Fixed in #7 (client) and 0xeb/libghidra#16 (host). Closing as a duplicate of #2.