There is heap corruption in windows using duckdb.dll caused by freeing memory in wrong module. On successfully opening a connection to duckdb, go-duckdb attempts to free the errMsg empty cgo string allocated in the golang executable by calling the duckdb_free(...) cgo wrapper func for duckdb.dll. This causes heap corruption and immediately panics. On connection error, duckdb.dll allocates the string for the error message so duckdb_free(...) correctly frees the memory.
duckdb_free(...) ultimately calls free(...) in duckdb.dll which safely handles null pointers (observed and documented) so easy fix was to just not allocate an empty string using C.String and leave it as null. Error messages continue to be allocated normally on connection error.
Problem
There is heap corruption in windows using duckdb.dll caused by freeing memory in wrong module. On successfully opening a connection to duckdb, go-duckdb attempts to free the errMsg empty cgo string allocated in the golang executable by calling the duckdb_free(...) cgo wrapper func for duckdb.dll. This causes heap corruption and immediately panics. On connection error, duckdb.dll allocates the string for the error message so duckdb_free(...) correctly frees the memory.
Issue https://github.com/marcboeker/go-duckdb/issues/24 appears to report this heap corruption.
Fix
duckdb_free(...) ultimately calls free(...) in duckdb.dll which safely handles null pointers (observed and documented) so easy fix was to just not allocate an empty string using C.String and leave it as null. Error messages continue to be allocated normally on connection error.