Bug: segfault

[MathGeniusJodie]

Describe the bug

here's the output of lldb, it looks like a double free

(lldb) cont
error: Process is running.  Use 'process interrupt' to pause execution.
Process 13694 stopped
* thread #22, stop reason = EXC_BAD_ACCESS (code=1, address=0x488)
    frame #0: 0x00000001055dcb50 kortex_grpc_server`unum::usearch::sorted_buffer_gt<unum::usearch::index_gt<float, unsigned long long, unsigned int, unum::usearch::aligned_allocator_gt<char, 64ul>, unum::usearch::memory_mapping_allocator_gt<64ul>>::candidate_t, std::__1::less<unum::usearch::index_gt<float, unsigned long long, unsigned int, unum::usearch::aligned_allocator_gt<char, 64ul>, unum::usearch::memory_mapping_allocator_gt<64ul>>::candidate_t>, unum::usearch::aligned_allocator_gt<unum::usearch::index_gt<float, unsigned long long, unsigned int, unum::usearch::aligned_allocator_gt<char, 64ul>, unum::usearch::memory_mapping_allocator_gt<64ul>>::candidate_t, 64ul>>::clear(this=0x0000000000000480) at index.hpp:690:42
   687      inline std::size_t size() const noexcept { return size_; }
   688      inline std::size_t capacity() const noexcept { return capacity_; }
   689      inline element_t const& top() const noexcept { return elements_[size_ - 1]; }
-> 690      inline void clear() noexcept { size_ = 0; }
   691  
   692      bool reserve(std::size_t new_capacity) noexcept {
   693          if (new_capacity < capacity_)
Target 0: (kortex_grpc_server) stopped.
(lldb) thread list
Process 13694 stopped
  thread #1: tid = 0xa964c9, 0x000000018665d06c libsystem_kernel.dylib`__psynch_cvwait + 8, name = 'main', queue = 'com.apple.main-thread'
  thread #2: tid = 0xa9650a, 0x00000001866597f0 libsystem_kernel.dylib`semaphore_wait_trap + 8, name = 'kortex_grpc_server'
  thread #3: tid = 0xa9650b, 0x000000018665d06c libsystem_kernel.dylib`__psynch_cvwait + 8, name = 'kortex_grpc_server'
  thread #4: tid = 0xa9650c, 0x000000018665d06c libsystem_kernel.dylib`__psynch_cvwait + 8, name = 'kortex_grpc_server'
  thread #5: tid = 0xa9650d, 0x000000018665d06c libsystem_kernel.dylib`__psynch_cvwait + 8, name = 'kortex_grpc_server'
  thread #6: tid = 0xa9650e, 0x000000018665d06c libsystem_kernel.dylib`__psynch_cvwait + 8, name = 'kortex_grpc_server'
  thread #7: tid = 0xa9650f, 0x000000018665d06c libsystem_kernel.dylib`__psynch_cvwait + 8, name = 'kortex_grpc_server'
  thread #8: tid = 0xa96510, 0x000000018665d06c libsystem_kernel.dylib`__psynch_cvwait + 8, name = 'kortex_grpc_server'
  thread #9: tid = 0xa96511, 0x000000018665d06c libsystem_kernel.dylib`__psynch_cvwait + 8, name = 'kortex_grpc_server'
  thread #10: tid = 0xa96512, 0x000000018665d06c libsystem_kernel.dylib`__psynch_cvwait + 8, name = 'kortex_grpc_server'
  thread #11: tid = 0xa96513, 0x000000018665d06c libsystem_kernel.dylib`__psynch_cvwait + 8, name = 'kortex_grpc_server'
  thread #12: tid = 0xa96514, 0x000000018665d06c libsystem_kernel.dylib`__psynch_cvwait + 8, name = 'kortex_grpc_server'
  thread #13: tid = 0xa96515, 0x000000018665d06c libsystem_kernel.dylib`__psynch_cvwait + 8, name = 'kortex_grpc_server'
  thread #14: tid = 0xa96516, 0x000000018665d06c libsystem_kernel.dylib`__psynch_cvwait + 8, name = 'kortex_grpc_server'
  thread #15: tid = 0xa96517, 0x000000018665d06c libsystem_kernel.dylib`__psynch_cvwait + 8, name = 'kortex_grpc_server'
  thread #16: tid = 0xa96518, 0x000000018665d06c libsystem_kernel.dylib`__psynch_cvwait + 8, name = 'kortex_grpc_server'
  thread #17: tid = 0xa96519, 0x000000018665d06c libsystem_kernel.dylib`__psynch_cvwait + 8, name = 'kortex_grpc_server'
  thread #18: tid = 0xa9651a, 0x000000018665d06c libsystem_kernel.dylib`__psynch_cvwait + 8
  thread #19: tid = 0xa9651b, 0x000000018665d06c libsystem_kernel.dylib`__psynch_cvwait + 8
  thread #20: tid = 0xa96775, 0x000000018665d06c libsystem_kernel.dylib`__psynch_cvwait + 8
  thread #21: tid = 0xa96777, 0x000000018665b524 libsystem_kernel.dylib`__workq_kernreturn + 8
* thread #22: tid = 0xa9ad76, 0x00000001055dcb50 kortex_grpc_server`unum::usearch::sorted_buffer_gt<unum::usearch::index_gt<float, unsigned long long, unsigned int, unum::usearch::aligned_allocator_gt<char, 64ul>, unum::usearch::memory_mapping_allocator_gt<64ul>>::candidate_t, std::__1::less<unum::usearch::index_gt<float, unsigned long long, unsigned int, unum::usearch::aligned_allocator_gt<char, 64ul>, unum::usearch::memory_mapping_allocator_gt<64ul>>::candidate_t>, unum::usearch::aligned_allocator_gt<unum::usearch::index_gt<float, unsigned long long, unsigned int, unum::usearch::aligned_allocator_gt<char, 64ul>, unum::usearch::memory_mapping_allocator_gt<64ul>>::candidate_t, 64ul>>::clear(this=0x0000000000000480) at index.hpp:690:42, stop reason = EXC_BAD_ACCESS (code=1, address=0x488)

Steps to reproduce

I can provide a reduced test case, but I'm just using basic functionality of the rust library, nothing fancy

Expected behavior

no segfault

USearch version

2.8.15

Operating System

Ubuntu 22.04.3

Hardware architecture

x86

Which interface are you using?

Other bindings

Contact Details

No response

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

[ashvardanian]

Thanks for the issue! Seems like it will be solved with the release of #339