Skip to content

fix: preserve state when copy assignment allocation fails - #179

Merged
gouyt13 merged 1 commit into
mainfrom
fix/copy-assignment-exception-safety
Oct 29, 2026
Merged

gouyt13 merged 1 commit into
mainfrom
fix/copy-assignment-exception-safety

Conversation

@gouyt13

@gouyt13 gouyt13 commented Oct 29, 2026

Copy link
Copy Markdown
Member

Summary

Preserve valid state when copy assignment runs out of memory in HashBasedVisitedSet, SplitSingleQuery, and FhtKacRotator. Prepare allocating storage before publishing metadata or borrowed pointers; the visited set copies both containers before replacing its state. Existing copy/move behavior, APIs and persisted layouts are preserved.

These are failure-recovery fixes for callers that catch an allocation exception and reuse the destination. No trigger was established in normal ANN build/search paths. Transactional visited-set copies may allocate a full replacement even when the destination has spare capacity.

Testing

  • Temporary fault-injection regressions failed before and passed after with ASan/UBSan: all four visited-set copy allocation sites, query state consistency, and rotator reuse. Also checked successful copies, self-assignment and existing move behavior. Probes are not committed; leak detection was disabled.
  • Portable Clang 23 Release CTest: 406 passed, 1 skipped; the skipped placement test passed separately with OpenMP binding enabled.
  • Repository formatting, git diff --check, and full clang-tidy passed (46 translation units, including bindings).

Python wheel tests were not rerun; no binding path invoking these assignments was identified.

@github-actions github-actions Bot added the release:fixed Release category managed from the PR title label Oct 29, 2026
@gouyt13
gouyt13 merged commit 90e0bbe into main Oct 29, 2026
39 checks passed
@gouyt13
gouyt13 deleted the fix/copy-assignment-exception-safety branch October 29, 2026 06:51
TamimEhsan pushed a commit to TamimEhsan/khorgosh that referenced this pull request Nov 2, 2026
num_threads=0 resolved to every available CPU and ignored the OpenMP thread
limit. Since 0.8.0 defaults add() to 0, txtai's 0.7-style add(x) started an
OpenMP worker team on macOS even though txtai sets OMP_NUM_THREADS=1 there.
With Faiss and PyTorch loaded, each bundling its own libomp, starting those
workers crashes (OMP Error VectorDB-NTU#179, then SIGSEGV).

Resolve 0 to min(available CPUs, omp_get_max_threads()) like Faiss does;
explicit positive requests are still capped only by the CPU count. Document
the limit and the macOS mixed-runtime caveat.

Fixes VectorDB-NTU#207
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

release:fixed Release category managed from the PR title

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant