Bug: PersistAndRestore C# test fails on MacOS
#454
Comments
ashvardanian
added
bug
|
was able to get a .NET7 env locally. can easily reproduce on the indicated SHA: it would appear that something about the cleanup in the finally block (and the accesses on the out arrays), causes the crash. here’s the full isolated output w a ton of dubug statements sprinkled throughout the test and the search method. Full test log output ⬇️ Determining projects to restore...
All projects are up-to-date for restore.
Cloud.Unum.USearch -> /Users/tito/code/usearch/csharp/src/Cloud.Unum.USearch/bin/Debug/netstandard2.0/Cloud.Unum.USearch.dll
Cloud.Unum.USearch.Tests -> /Users/tito/code/usearch/csharp/src/Cloud.Unum.USearch.Tests/bin/Debug/net7.0/Cloud.Unum.USearch.Tests.dll
NativeLibDir: /Users/tito/code/usearch/csharp/lib/
Files: /Users/tito/code/usearch/csharp/lib/runtimes/osx-arm64/native/libusearch_c.dylib
bin/Debug/net7.0/
Test run for /Users/tito/code/usearch/csharp/src/Cloud.Unum.USearch.Tests/bin/Debug/net7.0/Cloud.Unum.USearch.Tests.dll (.NETCoreApp,Version=v7.0)
Microsoft (R) Test Execution Command Line Tool Version 17.7.2 (arm64)
Copyright (c) Microsoft Corporation. All rights reserved.
Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
/Users/tito/code/usearch/csharp/src/Cloud.Unum.USearch.Tests/bin/Debug/net7.0/Cloud.Unum.USearch.Tests.dll
[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.4.5+1caef2f33e (64-bit .NET 7.0.20)
[xUnit.net 00:00:00.17] Discovering: Cloud.Unum.USearch.Tests
[xUnit.net 00:00:00.19] Discovered: Cloud.Unum.USearch.Tests
[xUnit.net 00:00:00.19] Starting: Cloud.Unum.USearch.Tests
Building index...
Built index
Adding vector System.Single[] to index....
Added vector System.Single[] to index
Saving index to path /Users/tito/code/usearch/csharp/src/Cloud.Unum.USearch.Tests/bin/Debug/net7.0/savedVectorFolder/tmp.usearch....
Saved index to path /Users/tito/code/usearch/csharp/src/Cloud.Unum.USearch.Tests/bin/Debug/net7.0/savedVectorFolder/tmp.usearch
Asserting file exists at /Users/tito/code/usearch/csharp/src/Cloud.Unum.USearch.Tests/bin/Debug/net7.0/savedVectorFolder/tmp.usearch
Asserting temp file exists at dir /Users/tito/code/usearch/csharp/src/Cloud.Unum.USearch.Tests/bin/Debug/net7.0/savedVectorFolder
Restoring index from /Users/tito/code/usearch/csharp/src/Cloud.Unum.USearch.Tests/bin/Debug/net7.0/savedVectorFolder/tmp.usearch...
Asserting restored index size...
Index assert succeeded, contains one vector
Searching index...
Initializing keys and distances arrays...
Keys and distances arrays initialized.
Pinning handles to query, keys, and distances...
Handles to query, keys, and distances pinned.
With pointers to pinned handles, calling native search...
Native search returned matches: 1
Native search error pointer: 0
Native search keys pointer: System.UInt64[]
Native search distances pointer: System.Single[]
Matches less than count, resizing keys&distances... 1 < 10
Resized keys and distances to match 1
Search OK
Freeing handles...
Freed handles.
Got matches: 1, keys: System.UInt64[]
Cleaning up...is it possible it’s a race related to how the memory for those inout arrays is freed after it’s pinned? i don’t know much about c# semantics, but when I comment out the handles free calls in the finally block, it passes about 1/5 of the time?! it still mostly fails tho. Test log success, no frees in finally blockHappy to spelunk further if this gives you any useful info! |
|
think I found it: index initialized as f64, seemingly intentionally by the comment which says "don't quantize": but the vector (as indexed and queried) is a float/f32, rather than a double/f64: this should do it: I'll put up a PR w this patch and unfiltering the test here in a few. |
|
Interesting. I believe using double is a good idea, but in either case the process shouldn't crash... I'd simply expect the following assertion to fail. So there may be a problem inferring the type of vector, assuming a larger buffer, writing out-of-bounds... and finally crashing. Can it be the case? |
|
yes something to that effect sounds likely — is it necessary the query vector align w the index precision type? and should add check/enforce the precision isn’t less than the index precision? quantization is one thing, so more precise must be allowed but an improperly configured index silently allowing less precise data seems like a potential footgun. perhaps it could cast the input vector to the appropriate type given the index’s expected precision as a middle ground? |
No, those are independent variables.
No need for that.
It performs the needed casts under the hood already. What's weird - this only appears on MacOS... and only with C# bindings/tests. |
|
Are there tests that exercise a similar code path on other platforms or for other languages? It seems like a mistake, rather than an intentional test case designed to pass a smaller than expected value. But agreed it ideally shouldn’t crash regardless. |
|
Not exactly the same test, but it should be easy to add in test.cpp using the test_punned_add_remove_vector function on the main-dev branch as a reference. |
Describe the bug
Weirdly, all C# tests pass on most platforms, but one of them fails on MacOS, and I don't know where it's coming from.
Steps to reproduce
On macOS with Arm-based chips:
This fails. But excluding that one test fixes things.
Expected behavior
Tests passing
USearch version
33c997e
Operating System
macOS Sonoma
Hardware architecture
Arm
Which interface are you using?
Other bindings
Contact Details
No response
Are you open to being tagged as a contributor?
.githistory as a contributorIs there an existing issue for this?
Code of Conduct
The text was updated successfully, but these errors were encountered: