Fix range-filtered tables returning 0 rows (#2, #3, #6) - #7
Merged
Conversation
The LibGhidraHost decodes the protobuf uint64 range-end into a signed Java long, so the kAllAddressesMax=UINT64_MAX sentinel arrived as -1 and tripped a getMaxAddress() fallback that emptied funcs/names/instructions/strings/xrefs/etc. for programs whose max address sits in a low-offset space (EXTERNAL block or file-backed sections). Use INT64_MAX so the sentinel stays positive on the host. Also drop two unused includes.
This was referenced Jun 23, 2026
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Range-filtered tables (
funcs,names,instructions,strings,xrefs,blocks,imports,exports, …) return 0 rows for many programs, while non-range tables (segments,types) and address-specific calls (decompile(addr),UPDATE … WHERE address=X) work. Reported in #2 (with correct root-cause), #3, and #6.Root cause
The client sends the range upper bound as
kAllAddressesMax = UINT64_MAX. The LibGhidraHost decodes the protobufuint64into a signed Javalong= -1, then falls back toprogram.getMaxAddress().getOffset(). For programs whose max address sits in a low-offset space (an EXTERNAL block, or file-backed "OTHER" sections at offset 0), the scan window collapses and the iterator breaks on the first real function → 0 rows. Programs without that layout (e.g. Mach-O/bin/ls) work by luck.Fix
Use
INT64_MAX(0x7FFFFFFFFFFFFFFF) so the sentinel stays positive on the host; the broken<= 0fallback never fires and the window includes every real address. One constant flows to all ~20List*call sites. Works against existing LibGhidraHost installs (no extension reinstall needed). Also drops two unused includes.The host-side companion hardening is 0xeb/libghidra#16 (either fix alone is sufficient).
Verification
Built a small Linux ELF (5 funcs, EXTERNAL refs) that triggers the bug:
/bin/lsregression unchanged (136 funcs). Addresses #2, #3, #6.