Container Overflow when calling DuckDB constructor

[shoehn]

What happens?

Address Sanitizer report a container-overflow, when running the constructor.

=================================================================
==25645==ERROR: AddressSanitizer: container-overflow on address 0x0001075009e7 at pc 0x00011c5090f4 bp 0x00016bd2d2c0 sp 0x00016bd2d2b8
READ of size 1 at 0x0001075009e7 thread T0
    #0 0x11c5090f0 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::__is_long[abi:ue170006]() const string:1734
    #1 0x11c508ef8 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::__get_pointer[abi:ue170006]() const string:1869
    #2 0x11c508e78 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::data[abi:ue170006]() const string:1559
    #3 0x11c5a98c4 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::append[abi:ue170006](std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&) string:1249
    #4 0x11c500080 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> std::__1::operator+[abi:ue170006]<char, std::__1::char_traits<char>, std::__1::allocator<char>>(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&) string:4201
    #5 0x1231892c4 in duckdb::FileSystem::JoinPath(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&) file_system.cpp:253
    #6 0x124d0d3a4 in duckdb::SecretManager::Initialize(duckdb::DatabaseInstance&) secret_manager.cpp:49
    #7 0x124eca004 in duckdb::DatabaseInstance::Initialize(char const*, duckdb::DBConfig*) database.cpp:245
    #8 0x124ece128 in duckdb::DuckDB::DuckDB(char const*, duckdb::DBConfig*) database.cpp:276
    #9 0x124ece5c8 in duckdb::DuckDB::DuckDB(char const*, duckdb::DBConfig*) database.cpp:275
    #10 0x1040d2a88 in main main.cpp:8
    #11 0x1888720dc  (<unknown module>)

0x0001075009e7 is located 23 bytes inside of 48-byte region [0x0001075009d0,0x000107500a00)
allocated by thread T0 here:
    #0 0x104cbd74c in wrap__Znwm+0x74 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x6174c)
    #1 0x11c43a280 in void* std::__1::__libcpp_operator_new[abi:ue170006]<unsigned long>(unsigned long) new:298
    #2 0x11c43a25c in std::__1::__libcpp_allocate[abi:ue170006](unsigned long, unsigned long) new:324
    #3 0x11c540ba8 in std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>::allocate[abi:ue170006](unsigned long) allocator.h:114
    #4 0x11c5404bc in std::__1::__allocation_result<std::__1::allocator_traits<std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>>::pointer> std::__1::__allocate_at_least[abi:ue170006]<std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>>(std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>&, unsigned long) allocate_at_least.h:55
    #5 0x11c53f0a0 in std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>>::__vallocate[abi:ue170006](unsigned long) vector:756
    #6 0x11d09d568 in std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>>::vector[abi:ue170006](std::initializer_list<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>) vector:1339
    #7 0x11d09d108 in duckdb::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, true>::vector(std::initializer_list<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>) vector.hpp:24
    #8 0x11cff9380 in duckdb::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, true>::vector(std::initializer_list<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>) vector.hpp:24
    #9 0x124d0cf9c in duckdb::SecretManager::Initialize(duckdb::DatabaseInstance&) secret_manager.cpp:47
    #10 0x124eca004 in duckdb::DatabaseInstance::Initialize(char const*, duckdb::DBConfig*) database.cpp:245
    #11 0x124ece128 in duckdb::DuckDB::DuckDB(char const*, duckdb::DBConfig*) database.cpp:276
    #12 0x124ece5c8 in duckdb::DuckDB::DuckDB(char const*, duckdb::DBConfig*) database.cpp:275
    #13 0x1040d2a88 in main main.cpp:8
    #14 0x1888720dc  (<unknown module>)

HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_container_overflow=0.
If you suspect a false positive see also: https://github.com/google/sanitizers/wiki/AddressSanitizerContainerOverflow.

SUMMARY: AddressSanitizer: container-overflow string:1734 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::__is_long[abi:ue170006]() const
Shadow bytes around the buggy address:
  0x000107500700: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x000107500780: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x000107500800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x000107500880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x000107500900: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x000107500980: fa fa fa fa fa fa fa fa fa fa fc fc[fc]fc fc fc
  0x000107500a00: fa fa 00 00 00 00 00 00 fa fa fd fd fd fd fd fd
  0x000107500a80: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x000107500b00: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd
  0x000107500b80: fa fa fd fd fd fd fd fd fa fa 00 00 00 00 00 fa
  0x000107500c00: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==25645==ABORTING

To Reproduce

I just compiled the minimal example from the getting started with CMake in CLion IDE:

#include "duckdb.hpp"

int main(int argc, char** argv) {

    duckdb::DuckDB db(nullptr);
    duckdb::Connection con(db);
    auto result = con.Query("SELECT 42");
    result->Print();
}

OS:

OSX on M1

DuckDB Version:

0.10.2

DuckDB Client:

C++

Full Name:

Sebastian Höhn

Affiliation:

BFH

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

I have tested with a stable release

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

Yes

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

[Mytherin]

Thanks for the report! I suspect this has to do with the way that DuckDB is built/linked. Can you make sure the header that you are using belongs to the library you are linking against (i.e. the versions are identical)? Using the header of one version of the library together with the shared object of another can cause all manners of undefined behavior.

[shoehn]

I thought about a false positive, too, but I could not justify, why it might be one.

The versions must be the same. I used CPM (https://github.com/cpm-cmake/CPM.cmake) to add the sources as a sub-module and compiled all the code with the same CMake settings. So I am 99% sure, that the versions of headers and libraries match.

[Mytherin]

Perhaps you have DuckDB in your include path elsewhere and it's grabbing the wrong header?

Could you provide a full set-up script that triggers the error, including your build process?

I don't really see how this can be anything other than a header mismatch or something funky happening in the build process. The address sanitizer reports an out-of-bounds on a concatenation of two std::strings, which is not possible when running C++ code normally.