host: unsigned-correct range filtering + fix unbounded getComments scan - #18
Merged
Conversation
Range-list handlers compared uint64 offsets as signed Java longs and special- cased <= 0, so addresses in the top half of the 64-bit space (>= INT64_MAX) were mishandled. Switch all 17 handlers to Long.compareUnsigned, take range bounds raw (default end = -1 = unbounded), and reset only the exact 0 start sentinel to minAddress (== 0, not <= 0) so a high start is never clobbered. This is a no-op for every address real binaries actually have; it removes the now-redundant resolveRangeEnd helper. Also fix getComments: it built an AddressSet up to the requested end (now INT64_MAX for 'all') and walked undefined code units across the empty gap to the top of the space, hanging 'SELECT ... FROM comments'. Clamp the end to the space max and intersect with loaded memory. Also tidy python/examples/pagination.py to INT64_MAX for consistency.
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
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.
Follow-up hardening to the range-end fix (#16).
Unsigned range filtering
The list handlers compared
uint64offsets as signed Java longs and special-cased<= 0, so addresses in the top half of the 64-bit space (≥INT64_MAX) were mishandled. All 17 handlers now useLong.compareUnsigned, take the range bounds raw (unbounded end =-1), and reset only the exact 0 start sentinel tominAddress(== 0, not<= 0) so a high start is never clobbered. Removes the now-redundantresolveRangeEndhelper.This is provably a no-op for every address real binaries have (signed and unsigned compare agree on non-negative longs) — verified:
/bin/lsand an ELF fixture return identical counts across funcs/names/instructions/strings/xrefs/blocks/data_items/exports/segments.getComments hang fix
getCommentsbuilt anAddressSetup to the requested end. After the range-end fix the client sendsINT64_MAX, so the set spanned to the top of the space andgetCodeUnitswalked undefined units across the empty gap — turningSELECT … FROM commentsinto a multi-second hang/timeout (the table was silently broken; never tested after #7/#16). Clamp the end to the space max and intersect with loaded memory.commentsnow returns a fast count (55 on/bin/ls).Also
python/examples/pagination.py:2**64-1→2**63-1for consistency with the C++ examples.No version bump.