Skip to content

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

Closed
@mapleFU

Description

@mapleFU

Describe the bug

The reason is raised from the issue below:

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;

                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?

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

Is there an existing issue for this?

  • I have searched the existing issues

Code of Conduct

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions