当 filesystem::path 被破坏时程序崩溃

Question

当 filesystem::path 被破坏时程序崩溃

Tur*_*000 5 c++ libstdc++ c++17 std-filesystem

以下程序崩溃：

#include <iostream>
#include <filesystem>
namespace fs = std::filesystem;
int main()
{
    fs::path p1 = "/usr/lib/sendmail.cf";
 
    std::cout << "p1 = " << p1 << '\n';
}

Run Code Online (Sandbox Code Playgroud)

汇编：

$ g++ -std=c++17 pathExistsTest.cpp
$ ./a.out 
p1 = "/usr/lib/sendmail.cf"
[1]    35688 segmentation fault (core dumped)  ./a.out

Run Code Online (Sandbox Code Playgroud)

在 Ubuntu 20.04 上测试，编译器为 GCC 8.4.0。

Valgrind，这是切割输出：

==30078==    by 0x4AE5034: QAbstractButton::mouseReleaseEvent(QMouseEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.12.8)
==30078==    by 0x4A312B5: QWidget::event(QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.12.8)
==30078==  Address 0x2b is not stack'd, malloc'd or (recently) free'd
==30078== 
==30078== 
==30078== Process terminating with default action of signal 11 (SIGSEGV)
==30078==  Access not within mapped region at address 0x2B
==30078==    at 0x13AD9B: std::vector<std::filesystem::__cxx11::path::_Cmpt, std::allocator<std::filesystem::__cxx11::path::_Cmpt> >::~vector() (in /home/(me)/src/tomato/build-src-Desktop-Release/TomatoLauncher)

Run Code Online (Sandbox Code Playgroud)

完整输出
我什至不知道为什么要调用向量 dtor？我只创建一个path变量，没有vector<path>。

Answer 1

dyp*_*dyp 20

TL; 博士

您正在使用 GCC 8.4.0 进行编译，因此您需要针对-lstdc++fs.

由于您使用的是 GCC 8.4.0，因此您使用的是 GCC 8.4.0 版的 GNU C++ 标准库，也就是 libstdc++ 头文件。但是您的系统（Ubuntu 20.04）仅包含libstdc++.so.6.0.28来自 GCC 9 的内容。如果您没有明确链接-lstdc++fs，那么您会不小心使用std::filesystem来自 GCC 9（via libstdc++.so）而不是来自 GCC 8（via libstdc++fs.a）的符号。

GCC 8 和 GCC 9 具有不兼容的std::filesystem类型。更具体地说，它们的二进制布局是不同的。这基本上是一个非常隐蔽的 ODR 违规。您的对象是为 GCC 8 布局分配的，但使用 GCC 9 布局构造。当您尝试销毁它时，析构函数使用 GCC 8 布局并崩溃，因为数据不是它所期望的。

有两段代码使用不同的、不兼容的path类型布局。

第一段代码来自libstdc++.so.6.0.28：它包含的定义path::_M_split_cmpts()，通过内联构造函数调用path::path(string_type&&, format)。由于构造函数是内联的，构造函数本身的代码会生成到您的可执行文件中。因此，您的可执行文件包含对path::_M_split_cmpts.

第二段代码在您自己的可执行文件中：它为内联（默认）析构函数path::~path()及其调用的内联函数生成指令；一直到std::filesystem::__cxx11::path::path<char [21], std::filesystem::__cxx11::path>(char const (&) [21], std::filesystem::__cxx11::path::path>(char const (&) [21], std::filesystem::__cxx11::path::format).

我们怎样才能找到这个？

使用调试器：单步执行 ctor 中的可疑函数显示：

0x5569716498ed <std::filesystem::__cxx11::path::path<char [21], std::filesystem::__cxx11::path>(char const (&) [21], std::filesystem::__cxx11::path::path>(char const (&) [21], std::filesystem::__cxx11::path::format)+112>       callq  0x5569716491e0 <_ZNSt10filesystem7__cxx114path14_M_split_cmptsEv@plt>

Run Code Online (Sandbox Code Playgroud)

这是通过 PLT 的调用（因此，可能来自共享对象，并且绝对不是内联的）。我们进入它并：

(gdb) bt
#0  0x00007f102c60f260 in std::filesystem::__cxx11::path::_M_split_cmpts() () from /lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x00005569716498ed in std::filesystem::__cxx11::path::path<char [21], std::filesystem::__cxx11::path> (this=0x7ffe1a07ad60, __source=...)
    at /usr/include/c++/8/bits/fs_path.h:185
#2  0x00005569716493fd in main () at blub.cpp:6

Run Code Online (Sandbox Code Playgroud)

所以，我们可以看到它确实来自/lib/x86_64-linux-gnu/libstdc++.so.6，它是到的符号链接/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28。

我们可以在 OP 的 Valgrind 输出中看到的 dtor：

==30078== Invalid read of size 8
==30078==    at 0x13AD9B: std::vector<std::filesystem::__cxx11::path::_Cmpt, std::allocator<std::filesystem::__cxx11::path::_Cmpt> >::~vector() (in /home/(me)/src/tomato/build-src-Desktop-Release/TomatoLauncher)

Run Code Online (Sandbox Code Playgroud)

它是内联的，因此在可执行文件中。

现在，真正有趣的部分是包含内联函数的头文件path和path::_M_split_cmpts函数都来自 GNU C++ 标准库 (libstdc++)。

他们怎么可能不相容？

为了回答这个问题，让我们来看看确切的版本。我们正在使用 GCC 8.4.0 进行编译。它包含在包含路径中，它们指的是 Ubuntu 20.04 的 gcc-8 包中提供的标准库头文件。它们完美匹配，您必须更改默认设置以使 GCC 使用不同的、不匹配的标准库头文件。因此，标头是 GCC 8.4.0 的标头。

共享对象libstdc++.so呢？我们正在运行libstdc++.so.6.0.28根据ldd和调试器。根据libstdc++ ABI Policy and Guidelines，这是GCC >= 9.3。

libstdc++.so.6.0.28 确实包含以下定义_ZNSt10filesystem7__cxx114path14_M_split_cmptsEv：

$ objdump -T /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28 | grep _ZNSt10filesystem7__cxx114path14_M_split_cmptsEv
000000000016a260 g    DF .text  00000000000005f3  GLIBCXX_3.4.26 _ZNSt10filesystem7__cxx114path14_M_split_cmptsEv

Run Code Online (Sandbox Code Playgroud)

根据 ABI 文档，这是

GCC 9.1.0：GLIBCXX_3.4.26、CXXABI_1.3.12

所以这是一个在 GCC 8.4.0 中不可用的符号。

为什么编译器/链接器不抱怨？

当我们使用 gcc-8 进行编译时，为什么编译器或链接器不会抱怨我们使用了 GCC 9 中的符号？

如果我们用编译-v，我们会看到链接器调用：

COLLECT_GCC_OPTIONS='-v' '-std=c++17' '-g' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/8/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/8/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper -plugin-opt=-fresolution=/tmp/cceJgWPt.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -z now -z relro /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/Scrt1.o /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/8/crtbeginS.o -L/usr/lib/gcc/x86_64-linux-gnu/8 -L/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/8/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/8/../../.. /tmp/ccTNph3u.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/8/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crtn.o                           COLLECT_GCC_OPTIONS='-v' '-std=c++17' '-g' '-shared-libgcc' '-mtune=generic' '-march=x86-64'

Run Code Online (Sandbox Code Playgroud)

在那里，我们有-L/usr/lib/gcc/x86_64-linux-gnu/8其他路径可以找到标准库。在那里，我们找到libstdc++.so -> ../../../x86_64-linux-gnu/libstdc++.so.6，它最终指向/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28(!!!)。

因此，链接器被赋予 GCC 9's libstdc++.so，并且它不会从编译器 (*) 接收有关符号的任何版本信息。编译器只知道源代码，在这种情况下，源代码不包含符号版本（GCC 8.4.0 的文件系统头文件）。然而，符号版本存在于 ELF 二进制文件中libstdc++.so。链接器查看GLIBCXX_3.4.26编译器请求的符号_ZNSt10filesystem7__cxx114path14_M_split_cmptsEv并对此感到满意。让你想知道是否有一个链接器开关来告诉链接器“如果我请求一个未版本化的符号，不要使用一个版本化的符号”。

(*) 链接器不会从编译器接收有关该未解析符号的任何符号信息，因为编译器没有来自源代码的此类信息。您可以在源代码中添加信息。我不知道 libstdc++ 通常是如何做的——或者它对头文件中符号版本的策略。看起来它根本没有为filesystem.

ELF 符号版本控制机制通常应防止此类不兼容：如果存在布局不兼容的更改，则创建一个名称相同但版本不同的新符号，并将其添加到libstdc++.so，然后包含旧版本和新版本。

编译的二进制文件libstdc++.so指定它想要哪个版本的符号，动态加载器根据匹配名称和版本的符号正确解析未定义的符号。请注意，动态链接器不知道要搜索哪个共享库（在 Windows/PE 上，这是不同的）。任何“符号请求”都只是一个未定义的符号，并且有一个完全独立的所需库列表来提供这些未定义的符号。但是二进制文件中没有映射哪个符号应该来自哪个库。

由于ELF符号版本机制允许符号的向后兼容的信息，我们可以保持一个单一 libstdc++.so的多个编译器版本。这就是为什么您会看到到处都是符号链接，导致所有文件都指向同一个文件。后缀.6.0.28是另一种正交版本控制方案，它允许向后不兼容的更改：您的二进制文件可以指定它需要的内容，libstdc++.so.6并且您可以添加与libstdc++.so.7其他二进制文件不兼容的文件。

有趣的事实：如果您将库链接到纯 GCC 8 版本libstdc++.so，您会看到链接器错误。链接共享库对二进制文件没有太大作用；然而，它确实修复了未解析符号的符号版本，并且可以在查看所有库后检查是否没有留下未解析的符号。我们可以看到，_ZNSt10filesystem7__cxx114path14_M_split_cmptsEv@GLIBCXX_3.4.26当您将二进制文件链接到libstdc++.so.6.0.28.

有趣的事实 2：如果您针对纯 GCC 8 版本运行您的库libstdc++.so，您会收到动态链接器错误，因为它找不到_ZNSt10filesystem7__cxx114path14_M_split_cmptsEv@GLIBCXX_3.4.26.

实际上应该发生什么？

您实际上应该链接到libstdc++fs.a. 它还提供了的定义_ZNSt10filesystem7__cxx114path14_M_split_cmptsEv，它不是符号链接，而是特定于此 GCC 版本：/usr/lib/gcc/x86_64-linux-gnu/8/libstdc++fs.a。

当您链接到时-lstdc++fs，您会将其符号直接包含在可执行文件中（因为它是一个静态库）。可执行文件中的符号优先于共享对象中的符号。因此，使用_ZNSt10filesystem7__cxx114path14_M_split_cmptsEvfrom libstdc++fs.a。

布局中的不兼容实际上是什么path？

GCC 9 引入了一种不同的类型来保存路径的组件。使用clang++ -cc1 -fdump-record-layouts，我们可以在左侧看到偏移量，在右侧看到成员和类型名称：

海湾合作委员会 8.4.0：

 0 | class std::filesystem::__cxx11::path
 0 |   class std::__cxx11::basic_string<char, struct std::char_traits<char>, class std::allocator<char> > _M_pathname
 0 |     struct std::__cxx11::basic_string<char, struct std::char_traits<char>, class std::allocator<char> >::_Alloc_hider _M_dataplus
 0 |       class std::allocator<char> (base) (empty)
 0 |         class __gnu_cxx::new_allocator<char> (base) (empty)
 0 |       std::__cxx11::basic_string<char, struct std::char_traits<char>, class std::allocator<char> >::pointer _M_p
 8 |     std::__cxx11::basic_string<char, struct std::char_traits<char>, class std::allocator<char> >::size_type _M_string_length
16 |     union std::__cxx11::basic_string<char, struct std::char_traits<char>, class std::allocator<char> >::(anonymous at /usr/include/c++/8/bits/basic_string.h:160:7) 
16 |       char [16] _M_local_buf
16 |       std::__cxx11::basic_string<char, struct std::char_traits<char>, class std::allocator<char> >::size_type _M_allocated_capacity
32 |   class std::vector<struct std::filesystem::__cxx11::path::_Cmpt, class std::allocator<struct std::filesystem::__cxx11::path::_Cmpt> > _M_cmpts
32 |     struct std::_Vector_base<struct std::filesystem::__cxx11::path::_Cmpt, class std::allocator<struct std::filesystem::__cxx11::path::_Cmpt> > (base)
32 |       struct std::_Vector_base<struct std::filesystem::__cxx11::path::_Cmpt, class std::allocator<struct std::filesystem::__cxx11::path::_Cmpt> >::_Vector_impl _M_impl
32 |         class std::allocator<struct std::filesystem::__cxx11::path::_Cmpt> (base) (empty)
32 |           class __gnu_cxx::new_allocator<struct std::filesystem::__cxx11::path::_Cmpt> (base) (empty)
32 |         std::_Vector_base<struct std::filesystem::__cxx11::path::_Cmpt, class std::allocator<struct std::filesystem::__cxx11::path::_Cmpt> >::pointer _M_start
40 |         std::_Vector_base<struct std::filesystem::__cxx11::path::_Cmpt, class std::allocator<struct std::filesystem::__cxx11::path::_Cmpt> >::pointer _M_finish
48 |         std::_Vector_base<struct std::filesystem::__cxx11::path::_Cmpt, class std::allocator<struct std::filesystem::__cxx11::path::_Cmpt> >::pointer _M_end_of_storage
56 |   enum std::filesystem::__cxx11::path::_Type _M_type
   | [sizeof=64, dsize=57, align=8,
   |  nvsize=57, nvalign=8]

Run Code Online (Sandbox Code Playgroud)

海湾合作委员会 9.3.0：

 0 | class std::filesystem::__cxx11::path
 0 |   class std::__cxx11::basic_string<char> _M_pathname
 0 |     struct std::__cxx11::basic_string<char, struct std::char_traits<char>, class std::allocator<char> >::_Alloc_hider _M_dataplus
 0 |       class std::allocator<char> (base) (empty)
 0 |         class __gnu_cxx::new_allocator<char> (base) (empty)
 0 |       std::__cxx11::basic_string<char, struct std::char_traits<char>, class std::allocator<char> >::pointer _M_p
 8 |     std::__cxx11::basic_string<char, struct std::char_traits<char>, class std::allocator<char> >::size_type _M_string_length
16 |     union std::__cxx11::basic_string<char, struct std::char_traits<char>, class std::allocator<char> >::(anonymous at /usr/include/c++/9/bits/basic_string.h:171:7) 
16 |       char [16] _M_local_buf
16 |       std::__cxx11::basic_string<char, struct std::char_traits<char>, class std::allocator<char> >::size_type _M_allocated_capacity
32 |   struct std::filesystem::__cxx11::path::_List _M_cmpts
32 |     class std::unique_ptr<struct std::filesystem::__cxx11::path::_List::_Impl, struct std::filesystem::__cxx11::path::_List::_Impl_deleter> _M_impl
32 |       class std::__uniq_ptr_impl<struct std::filesystem::__cxx11::path::_List::_Impl, struct std::filesystem::__cxx11::path::_List::_Impl_deleter> _M_t
32 |         class std::tuple<struct std::filesystem::__cxx11::path::_List::_Impl *, struct std::filesystem::__cxx11::path::_List::_Impl_deleter> _M_t
32 |           struct std::_Tuple_impl<0, struct std::filesystem::__cxx11::path::_List::_Impl *, struct std::filesystem::__cxx11::path::_List::_Impl_deleter> (base)
32 |             struct std::_Tuple_impl<1, struct std::filesystem::__cxx11::path::_List::_Impl_deleter> (base) (empty)
32 |               struct std::_Head_base<1, struct std::filesystem::__cxx11::path::_List::_Impl_deleter, true> (base) (empty)
32 |                 struct std::filesystem::__cxx11::path::_List::_Impl_deleter (base) (empty)
32 |             struct std::_Head_base<0, struct std::filesystem::__cxx11::path::_List::_Impl *, false> (base)
32 |               struct std::filesystem::__cxx11::path::_List::_Impl * _M_head_impl
   | [sizeof=40, dsize=40, align=8,
   |  nvsize=40, nvalign=8]

Run Code Online (Sandbox Code Playgroud)

不同之处在于path::_M_cmpts：

// GCC 8
class std::vector<
  struct std::filesystem::__cxx11::path::_Cmpt,
  class std::allocator<struct std::filesystem::__cxx11::path::_Cmpt>
> _M_cmpts

// GCC 9
struct std::filesystem::__cxx11::path::_List _M_cmpts

Run Code Online (Sandbox Code Playgroud)

您还可以path::_List在上面的记录转储中看到的结构。它与 GCC 8 非常不兼容vector。

请记住，我们是path::_M_split_cmpts通过 GCC 9 中的 libstdc++.so调用的，并且我们在vector该_M_cmpts数据成员的析构函数中崩溃了。

这里的承诺，从改变vector到_List：

commit 4f87bb8d6e8dec21a07f1fba641a78a127281349
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Dec 13 20:33:55 2018 +0000

PR libstdc++/71044 optimize std::filesystem::path construction

This new implementation has a smaller footprint than the previous
implementation, due to replacing std::vector<_Cmpt> with a custom pimpl
type that only needs a single pointer. The _M_type enumeration is also
combined with the pimpl type, by using a tagged pointer, reducing
sizeof(path) further still.

Construction and modification of paths is now done more efficiently, by
splitting the input into a stack-based buffer of string_view objects
instead of a dynamically-allocated vector containing strings. Once the
final size is known only a single allocation is needed to reserve space
for it.  The append and concat operations no longer require constructing
temporary path objects, nor re-parsing the entire native pathname.
This results in algorithmic improvements to path construction, and
working with large paths is much faster.

Run Code Online (Sandbox Code Playgroud)

我已经好久没有玩过这么开心了！xD (4认同)
感谢您付出的努力！很高兴我的问题能给你带来一些乐趣。：D (4认同)

归档时间：	5 年，3 月前
查看次数：	894 次
最近记录：	5 年，2 月前