Bug: QUERY_VECTOR_INDEX causes SIGSEGV on macOS ARM64 #866

Ladybug version

0.20.0

What operating system are you using?

macOS: 26.5.2

What happened?

QUERY_VECTOR_INDEX causes SIGSEGV on macOS ARM64

Environment

• LadybugDB: 0.20.0
• Python: 3.11.16
• Architecture: arm64 native
• macOS: 26.5.2
• Hardware: Apple M2
• Installation: pip install ladybug using the native ARM64 wheel

Problem

CREATE_VECTOR_INDEX completes successfully, but querying the resulting index with QUERY_VECTOR_INDEX immediately terminates the Python process with:

Segmentation fault: 11

No Python exception is raised.

Are there known steps to reproduce?

Minimal reproduction

import ladybug as lb
db = lb.Database("vector_crash.lbdb")
c = lb.Connection(db)
c.execute("""
CREATE NODE TABLE Contribution(
id STRING,
embedding FLOAT[4],
PRIMARY KEY(id)
)
""")
for id_, emb in [
("c1", [1.0, 0.0, 0.2, 0.0]),
("c2", [0.0, 1.0, 0.0, 0.2]),
("c3", [0.8, 0.0, 0.1, 0.0]),
]:
c.execute(
"CREATE (:Contribution {id:$id, embedding:$embedding})",
{"id": id_, "embedding": emb}
)
c.execute("INSTALL VECTOR")
c.execute("LOAD EXTENSION VECTOR")
c.execute("""
CALL CREATE_VECTOR_INDEX(
'Contribution',
'contrib_vec',
'embedding'
)
""")
print("before query", flush=True)
r = c.execute("""
CALL QUERY_VECTOR_INDEX(
'Contribution',
'contrib_vec',
[1.0, 0.0, 0.2, 0.0],
2
)
RETURN node.id, distance
""")
print("after query", flush=True)
while r.has_next():
print(r.get_next())

Output:

before query
Segmentation fault: 11

Additional isolation

The following operations have been tested successfully in the same environment:

• Basic Connection.execute()
• Parameter binding
• Node creation and retrieval
• Relationship creation and traversal
• Relationship properties
• MERGE
• Storing and retrieving FLOAT[4] properties
• FTS extension, including CREATE_FTS_INDEX and QUERY_FTS_INDEX
• INSTALL VECTOR
• LOAD EXTENSION VECTOR
• CREATE_VECTOR_INDEX

A separate test stopping immediately after CREATE_VECTOR_INDEX exits normally:

before install
after install
after load
after create index

Therefore the crash appears specifically when executing QUERY_VECTOR_INDEX, rather than while loading the extension, storing vectors, or constructing the HNSW index.

The same broader application initially crashed under Python 3.14 ARM64 as well. Python 3.11 ARM64 was then used to produce the minimal reproduction above.

As an additional test, I also tried brute-force cosine similarity without creating or querying a vector index:

ARRAY_COSINE_SIMILARITY(c.embedding, [1.0, 0.0, 0.2, 0.0])

This also causes Segmentation fault: 11.

Storing and retrieving the same FLOAT[4] values works correctly, so the crash appears to be triggered when vector similarity computation is executed, not by the vector property itself.