DuckDB fails to create an HNSW index.

[loloxwg]

What happens?

If following the Versioning of Extensions documentation leads to a crash after creating a new table, inserting data into a vector table, and creating an index, it likely indicates an issue with the database setup, extension compatibility, or versioning.

To Reproduce

INSTALL vss;
LOAD vss;

CREATE TABLE my_vector_table (vec FLOAT[3]);
INSERT INTO my_vector_table SELECT array_value(a, b, c) FROM range(1, 10) ra(a), range(1, 10) rb(b), range(1, 10) rc(c);
CREATE INDEX my_hnsw_index ON my_vector_table USING HNSW (vec);

OS:

macos 14.2.1

DuckDB Version:

v1.1.4-dev4271 d707b4432b

DuckDB Client:

cli

Hardware:

Apple M1 Pro

Full Name:

xuanwei zhang

Affiliation:

kipdata

What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.

I have tested with a source build

Did you include all relevant data sets for reproducing the issue?

No - Other reason (please specify in the issue body)

Did you include all code required to reproduce the issue?

• Yes, I have

Did you include all relevant configuration (e.g., CPU architecture, Python version, Linux distribution) to reproduce the issue?

• Yes, I have

[Maxxen]

Are you compiling DuckDB yourself but using the nightly pre-built vss binary, or are you compiling vss too?

[loloxwg]

I just use clion and ran the config shell @Maxxen

[Maxxen]

Ok, so you did not compile vss from source?

My guess is that the issue is related to ASAN being enabled in DuckDB, but not in the vss extension, causing the false positive error when executing the vss code. If that is the case this is not a bug, you just need to compile vss with asan enabled as part of your duckdb build or disable asan when building duckdb.

[loloxwg]

How can I disable AddressSanitizer (ASAN)? @Maxxen

[Maxxen]

[Maxxen]

But if you want to build DuckDB WITH vss yourself (not using the pre-built nightly version you download when you run INSTALL vss), you should read this: https://github.com/duckdb/duckdb/tree/main/extension#readme

[loloxwg]

option(ENABLE_EXTENSION_AUTOLOADING "Enable extension auto-loading by default." FALSE)
option(ENABLE_EXTENSION_AUTOINSTALL "Enable extension auto-installing by default." FALSE)
option(EXTENSION_TESTS_ONLY "Only load the tests for extensions, don't actually build them; useful for testing loadable extensions" FALSE)
option(WASM_LOADABLE_EXTENSIONS "WebAssembly build with loadable extensions." FALSE)
option(ENABLE_SANITIZER "Enable address sanitizer." FALSE)
option(ENABLE_THREAD_SANITIZER "Enable thread sanitizer." FALSE)
option(ENABLE_UBSAN "Enable undefined behavior sanitizer." TRUE)
option(DISABLE_VPTR_SANITIZER "Disable vptr sanitizer; work-around for sanitizer false positive on Macbook M1" TRUE)

Thank you for sharing! By modifying the code, you successfully executed the CREATE INDEX statement—great work! @Maxxen

[loloxwg]

How can I resolve the issue of DuckDB crashing without showing an error message when I input an incorrect SQL statement on an M1 Mac? Could this be related to compilation options?

[Maxxen]

The issue is still the same, you're running a locally built DuckDB (built in debug mode), but loading a released vss binary (built in release mode), I don't think there is any guarantee that it will work. You should make sure to build the vss extension locally (in debug) mode as well, the docs I linked explain how that works.

[loloxwg]

When running a locally compiled program in debug mode (Mac OS m1), entering any invalid SQL statement (without loading plugins) causes the program to crash directly instead of returning an error.On my macOS system, the program seems to behave differently compared to Linux. When running in debug mode on Linux, I can see that errors are being caught, and the program does not crash.

@Maxxen

[loloxwg]

Resolved by utilizing the default macOS C++ build tools. The primary issue was a mismatch in the libwind version. @Maxxen