Segmentation fault in std::__1::__libcpp_db::swap with -D_LIBCPP_DEBUG=1

[maflcko]

Steps to reproduce:

cat /tmp/fs.cpp:

#include <filesystem>
#include <iostream>
struct Path : public std::filesystem::path {
  Path(std::filesystem::path p) : std::filesystem::path{std::move(p)} {}
};
Path Absolute(const char* p) {
  return std::filesystem::absolute(p);
}
int main() {
  Absolute("/aaaaaaaaaaaaaaaaaaaaa");
  std::cout << __LINE__ << std::endl;
  Absolute("/aaaaaaaaaaaaaaaaaaaaaa");
  std::cout << __LINE__ << std::endl;
}

clang++-15 -stdlib=libc++ -std=c++17 -D_LIBCPP_DEBUG=1 /tmp/fs.cpp && valgrind ./a.out:

==6453== Memcheck, a memory error detector
==6453== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==6453== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==6453== Command: ./a.out
==6453== 
11
==6453== Invalid read of size 8
==6453==    at 0x48A8EC7: std::__1::__libcpp_db::swap(void*, void*) (in /usr/lib/llvm-15/lib/libc++.so.1.0)
==6453==    by 0x10A8D1: std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_string(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&&) (in /a.out)
==6453==    by 0x10A82C: std::__1::__fs::filesystem::path::path(std::__1::__fs::filesystem::path&&) (in /a.out)
==6453==    by 0x10A4EF: Path::Path(std::__1::__fs::filesystem::path) (in /a.out)
==6453==    by 0x10A32C: Absolute(char const*) (in /a.out)
==6453==    by 0x10A3E0: main (in /a.out)
==6453==  Address 0x8 is not stack'd, malloc'd or (recently) free'd
==6453== 
==6453== 
==6453== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==6453==  Access not within mapped region at address 0x8
==6453==    at 0x48A8EC7: std::__1::__libcpp_db::swap(void*, void*) (in /usr/lib/llvm-15/lib/libc++.so.1.0)
==6453==    by 0x10A8D1: std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_string(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&&) (in /a.out)
==6453==    by 0x10A82C: std::__1::__fs::filesystem::path::path(std::__1::__fs::filesystem::path&&) (in /a.out)
==6453==    by 0x10A4EF: Path::Path(std::__1::__fs::filesystem::path) (in /a.out)
==6453==    by 0x10A32C: Absolute(char const*) (in /a.out)
==6453==    by 0x10A3E0: main (in /a.out)
==6453==  If you believe this happened as a result of a stack
==6453==  overflow in your program's main thread (unlikely but
==6453==  possible), you can try to increase the size of the
==6453==  main thread stack using the --main-stacksize= flag.
==6453==  The main thread stack size used in this run was 8388608.
==6453== 
==6453== HEAP SUMMARY:
==6453==     in use at exit: 192 bytes in 5 blocks
==6453==   total heap usage: 8 allocs, 3 frees, 1,312 bytes allocated
==6453== 
==6453== LEAK SUMMARY:
==6453==    definitely lost: 0 bytes in 0 blocks
==6453==    indirectly lost: 0 bytes in 0 blocks
==6453==      possibly lost: 0 bytes in 0 blocks
==6453==    still reachable: 192 bytes in 5 blocks
==6453==         suppressed: 0 bytes in 0 blocks
==6453== Rerun with --leak-check=full to see details of leaked memory
==6453== 
==6453== For lists of detected and suppressed errors, rerun with: -s
==6453== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

clang++-15 --version:

Ubuntu clang version 15.0.0-++20220206064150+31626cc111c0-1~exp1~20220206184250.150
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

[llvmbot]

@llvm/issue-subscribers-bug

[maflcko]

@llvm/issue-subscribers-libcxx

[ryanofsky]

I'm able to reproduce the problem with a slightly more minimal example:

#include <filesystem>
int main() {
  std::filesystem::absolute("/aaaaaaaaaaaaaaaaaaaaa");
  std::filesystem::path p1 = std::filesystem::absolute("/aaaaaaaaaaaaaaaaaaaaaa");
  std::filesystem::path p2 = std::move(p1);
}

with clang++ -g -std=c++17 fs.cpp -D_LIBCPP_DEBUG=1 -stdlib=libc++

stack trace

#0  0x00007ffff7efbb74 in std::__1::__libcpp_db::swap(void*, void*) () from /nix/store/amx4anb4r9rkrg532wavn7kxck2agdwy-libcxx-13.0.0/lib/libc++.so.1
#1  0x00000000004023ae in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_string (this=0x7fffffff96e0, __str=...) at /nix/store/3vhxc3r7dkmgyg465gvp1f94f4sbr2v8-libcxx-13.0.0-dev/include/c++/v1/string:1998
#2  std::__1::__fs::filesystem::path::path (this=0x7fffffff96e0, __p=...) at /nix/store/3vhxc3r7dkmgyg465gvp1f94f4sbr2v8-libcxx-13.0.0-dev/include/c++/v1/filesystem:941
#3  main () at fs.cpp:5

This is using older clang-13.0.0 in nix-shell with shell.nix

with import <nixpkgs> {};
llvmPackages_13.libcxxStdenv.mkDerivation {
  name = "clang-nix-shell";
  buildInputs = [ llvmPackages_13.libcxx llvmPackages_13.libcxxabi valgrind ];
}

[philnik777]

This happens most likely because the dylib wasn't built with the debug-mode enabled. This isn't a supported configuration anymore, so I'm closing this.