Bug: index_gt::search_to_find_in_base_ might call top when it's empty

[mapleFU]

trafficstars

Describe the bug

The reason is raised from the issue below:

https://github.com/unum-cloud/usearch/blob/e414f46b440fc2b989aca648fecfc4db35e22332/include/usearch/index.hpp#L4180-L4183

                if (top.size() < top_limit || successor_dist < radius) {
                    // This can substantially grow our priority queue:
                    next.insert({-successor_dist, successor_slot});
                    if (is_dummy<predicate_at>() ||
                        predicate(member_cref_t{node_at_(successor_slot).ckey(), successor_slot}))
                        top.insert({successor_dist, successor_slot}, top_limit);
                    radius = top.top().distance;
                }

when predicate_at is not dummy, and predicate returns false. top might remains empty. And radius = top.top().distance might be invalid

Steps to reproduce

Select with predicate might trigger the issue. We can assume a all-false searching.

Expected behavior

Not trigger the coredump here.

USearch version

v2.17.7

Operating System

MacOS 12.7

Hardware architecture

x86

Which interface are you using?

C++ implementation

Contact Details

[email protected]

Are you open to being tagged as a contributor?

• [x] I am open to being mentioned in the project .git history as a contributor

Is there an existing issue for this?

• [x] I have searched the existing issues

Code of Conduct

• [x] I agree to follow this project's Code of Conduct

[ashvardanian]

Interesting, @mapleFU! I would assume, we don't even have tests covering failing predicates. May help to add some!

[mapleFU]

I'd glad to but currently I'm focus on another problem, maybe wait for one day

[mapleFU]

Note:

inline element_t const& top() const noexcept { return elements_[size_ - 1]; }

This might cause elements[-1] visited

[mapleFU]

I've update the fix and test here: https://github.com/unum-cloud/usearch/pull/599