test(similarity): cover the empty-graph qsort null base (#1367) - #1476
Merged
Conversation
The production guard for #1367 — collect_fp_entries only sorting when count > 1 — is on main, but nothing exercises it. A fix without a test is a fix that can be silently undone, and this one is unusually easy to undo: removing the guard produces no visible symptom on most lanes. Adds the missing case: a graph with zero Function/Method nodes, where the entry array is never allocated and the null base would reach qsort. The test comment records WHERE the test binds, because that turned out to be the interesting part. Removing the guard again: macOS 25 passed (Apple libc does not mark qsort nonnull, so there is no UB to see) Linux ASan/UBSan, recovering 25 passed (prints "null pointer passed as argument 1", then keeps going) Linux UBSan, trapping exit 1 (process aborts — the RED) So the assertions here are the behavioural half (empty graph → rc 0, no SIMILAR_TO edges), and the UB half is caught by the trap-UBSan leg alone. Both were measured on ubuntu-arm64 in each direction. Spelling that out in the test keeps a future reader from checking it on a recovering lane, seeing green, and concluding the null-base guard is still there when it is not. Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
DeusData
enabled auto-merge
August 6, 2026 16:42
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.
Why
The production guard for #1367 —
collect_fp_entriesonly sorting whencount > 1— is on main, but nothing exercises it. A fix without a test is a fix that can be silently undone, and this one is unusually easy to undo: removing the guard produces no visible symptom on most lanes.What
A graph with zero
Function/Methodnodes, where the entry array is never allocated and the null base would otherwise reachqsort.Where this test binds — the interesting part
I removed the guard again and measured, rather than assuming:
25 passed— Apple libc doesn't markqsortnonnull, so there is no UB to observe25 passed— printsnull pointer passed as argument 1, then continues-fno-sanitize-recover)With the guard restored, the trapping lane is
25 passedagain.So the assertions are the behavioural half (empty graph →
rc 0, noSIMILAR_TOedges), and the UB half is caught by the trap-UBSan leg alone. That split is written into the test comment deliberately: without it, a future reader checks this on a recovering lane, sees green, and concludes the null-base guard is still in place when it is not — exactly the false-guard shape.Verification
macOS
simhashsuite green (25 passed);make lint-ciclean. Both directions measured on ubuntu-arm64 as tabulated above.