flto 与 gcc7.2 崩溃

Question

我在以下代码文件中遇到 getline 崩溃。我构建了 gcc7.2，因为系统更新不可用。

最小示例：

#include <iostream>

int main(int argc, char *argv[])
{
    std::string line;
    while (std::getline(std::cin, line))
    {
    }
    return 0;
}

下面几行，GCC_INSTALL_DIR代表我自己的gcc安装目录输出：

./a.out 
a
*** Error in `./a.out': free(): invalid pointer: 0x0000000000602200 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7cfe1)[0x7f392a8f3fe1]
[GCC_INSTALL_DIR]/generated/lib64/libstdc++.so.6(_ZNSs7reserveEm+0x85)[0x7f392b221cd5]
[GCC_INSTALL_DIR]/generated/lib64/libstdc++.so.6(_ZSt7getlineIcSt11char_traitsIcESaIcEERSt13basic_istreamIT_T0_ES7_RSbIS4_S5_T1_ES4_+0x175)[0x7f392b1fa675]
./a.out[0x40120d]
./a.out[0x4010a9]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f392a898b15]
./a.out[0x400f29]
======= Memory map: ========
00400000-00402000 r-xp 00000000 08:05 3312183238                         [redacted]/a.out
00601000-00602000 r--p 00001000 08:05 3312183238                         [redacted]/a.out
00602000-00603000 rw-p 00002000 08:05 3312183238                         [redacted]/a.out
008a6000-008d8000 rw-p 00000000 00:00 0                                  [heap]
7f3924000000-7f3924021000 rw-p 00000000 00:00 0 
7f3924021000-7f3928000000 ---p 00000000 00:00 0 
7f392a877000-7f392aa2d000 r-xp 00000000 08:03 201329280                  /usr/lib64/libc-2.17.so
7f392aa2d000-7f392ac2d000 ---p 001b6000 08:03 201329280                  /usr/lib64/libc-2.17.so
7f392ac2d000-7f392ac31000 r--p 001b6000 08:03 201329280                  /usr/lib64/libc-2.17.so
7f392ac31000-7f392ac33000 rw-p 001ba000 08:03 201329280                  /usr/lib64/libc-2.17.so
7f392ac33000-7f392ac38000 rw-p 00000000 00:00 0 
7f392ac38000-7f392ac4e000 r-xp 00000000 08:05 93316545                   [GCC_INSTALL_DIR]/generated/lib64/libgcc_s.so.1
7f392ac4e000-7f392ae4d000 ---p 00016000 08:05 93316545                   [GCC_INSTALL_DIR]/generated/lib64/libgcc_s.so.1
7f392ae4d000-7f392ae4e000 r--p 00015000 08:05 93316545                   [GCC_INSTALL_DIR]/generated/lib64/libgcc_s.so.1
7f392ae4e000-7f392ae4f000 rw-p 00016000 08:05 93316545                   [GCC_INSTALL_DIR]/generated/lib64/libgcc_s.so.1
7f392ae4f000-7f392af50000 r-xp 00000000 08:03 201329288                  /usr/lib64/libm-2.17.so
7f392af50000-7f392b14f000 ---p 00101000 08:03 201329288                  /usr/lib64/libm-2.17.so
7f392b14f000-7f392b150000 r--p 00100000 08:03 201329288                  /usr/lib64/libm-2.17.so
7f392b150000-7f392b151000 rw-p 00101000 08:03 201329288                  /usr/lib64/libm-2.17.so
7f392b151000-7f392b2c3000 r-xp 00000000 08:05 93812046                   [GCC_INSTALL_DIR]/generated/lib64/libstdc++.so.6.0.24
7f392b2c3000-7f392b4c2000 ---p 00172000 08:05 93812046                   [GCC_INSTALL_DIR]/generated/lib64/libstdc++.so.6.0.24
7f392b4c2000-7f392b4cc000 r--p 00171000 08:05 93812046                   [GCC_INSTALL_DIR]/generated/lib64/libstdc++.so.6.0.24
7f392b4cc000-7f392b4ce000 rw-p 0017b000 08:05 93812046                   [GCC_INSTALL_DIR]/generated/lib64/libstdc++.so.6.0.24
7f392b4ce000-7f392b4d2000 rw-p 00000000 00:00 0 
7f392b4d2000-7f392b4f3000 r-xp 00000000 08:03 201329241                  /usr/lib64/ld-2.17.so
7f392b6d4000-7f392b6d9000 rw-p 00000000 00:00 0 
7f392b6f0000-7f392b6f3000 rw-p 00000000 00:00 0 
7f392b6f3000-7f392b6f4000 r--p 00021000 08:03 201329241                  /usr/lib64/ld-2.17.so
7f392b6f4000-7f392b6f5000 rw-p 00022000 08:03 201329241                  /usr/lib64/ld-2.17.so
7f392b6f5000-7f392b6f6000 rw-p 00000000 00:00 0 
7fff7363e000-7fff7365f000 rw-p 00000000 00:00 0                          [stack]
7fff7374b000-7fff7374d000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Abandon (core dumped)


[GCC_INSTALL_DIR]/generated/bin/g++ -c -g -I[GCC_INSTALL_DIR]/generated/include/c++/7.2.0 -std=c++17 -flto -o main.o main.cpp -D_GLIBCXX_USE_CXX11_ABI=0 && [GCC_INSTALL_DIR]/generated/bin/g++ -flto main.o

链接库：

ldd ./a.out 
        linux-vdso.so.1 =>  (0x00007ffcf9fe6000)
        libstdc++.so.6 => [GCC_INSTALL_DIR]/generated/lib64/libstdc++.so.6 (0x00007f04a565e000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f04a5342000)
        libgcc_s.so.1 => [GCC_INSTALL_DIR]/generated/lib64/libgcc_s.so.1 (0x00007f04a512b000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f04a4d6a000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f04a59e00

libc 版本：

ldd --version
    ldd (GNU libc) 2.1700)

gcc7.2 的配置选项

$OLD_PWD/gcc-7.2.0/configure --prefix=$OLD_PWD/generated --disable-multilib

编译命令行：

[GCC_INSTALL_DIR]/generated/bin/g++ -c -g -I[GCC_INSTALL_DIR]/generated/include/c++/7.2.0 -std=c++17 -flto -o main.o main.cpp -D_GLIBCXX_USE_CXX11_ABI=0 && [GCC_INSTALL_DIR]/generated/bin/g++ -flto main.o

Valgrind 输出：

==28919== Memcheck, a memory error detector
==28919== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==28919== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==28919== Command: ./a.out
==28919== 
a
==28919== Invalid free() / delete / delete[] / realloc()
==28919==    at 0x4C2B131: operator delete(void*) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==28919==    by 0x4F05CD4: _M_dispose (basic_string.h:3155)
==28919==    by 0x4F05CD4: std::string::reserve(unsigned long) (basic_string.tcc:961)
==28919==    by 0x4EDE674: push_back (basic_string.h:4109)
==28919==    by 0x4EDE674: operator+= (basic_string.h:3966)
==28919==    by 0x4EDE674: std::basic_istream<char, std::char_traits<char> >& std::getline<char, std::char_traits<char>, std::allocator<char> >(std::basic_istream<char, std::char_traits<char> >&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, char) (istream-string.cc:168)
==28919==    by 0x40120C: std::basic_istream<char, std::char_traits<char> >& std::getline<char, std::char_traits<char>, std::allocator<char> >(std::basic_istream<char, std::char_traits<char> >&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&) (in /home/elie/dev/a.out)
==28919==    by 0x4010A8: main (in /home/elie/dev/a.out)
==28919==  Address 0x602200 is 0 bytes inside data symbol "_ZNSs4_Rep20_S_empty_rep_storageE"
==28919== 
a
a
==28919== 
==28919== HEAP SUMMARY:
==28919==     in use at exit: 72,704 bytes in 1 blocks
==28919==   total heap usage: 2 allocs, 2 frees, 72,730 bytes allocated
==28919== 
==28919== LEAK SUMMARY:
==28919==    definitely lost: 0 bytes in 0 blocks
==28919==    indirectly lost: 0 bytes in 0 blocks
==28919==      possibly lost: 0 bytes in 0 blocks
==28919==    still reachable: 72,704 bytes in 1 blocks
==28919==         suppressed: 0 bytes in 0 blocks
==28919== Rerun with --leak-check=full to see details of leaked memory
==28919== 
==28919== For counts of detected and suppressed errors, rerun with: -v
==28919== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 1 from 1)

我们必须使用 _GLIBCXX_USE_CXX11_ABI=0 因为我们与旧库交互。

删除 flto、_GLIBCXX_USE_CXX11_ABI=0 或将 -std=c++17 更改为 -std=c++14 可解决崩溃问题。

这是 gcc-7.2 的错误还是我遗漏了什么？我应该向 gcc 提交错误报告吗？

我宁愿避免禁用 flto 或 c++17

的解决方法

编辑： gcc7.2 中存在错误：https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82172

Answer 1

旧版本的 binutils 存在错误。

使用 binutils-2.28 构建解决了这些问题。

相关 gcc bugzilla : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82172

flto 与 gcc7.2 崩溃

flto crash with gcc7.2

c++

gcc

c++17

gcc7