C++ 程序在执行 std::string 分配时总是崩溃

2022-01-12 00:00:00 gdb crash c++ valgrind stdstring

我一直在尝试调试我的应用程序崩溃(即断言* 检测到 glibc * free(): invalid pointer: 0x000000000070f0c0 ***) 而我正在尝试对字符串进行简单的分配.请注意，我正在使用 gcc 4.2.4 的 linux 系统上编译，优化级别设置为 -O2.使用 -O0，应用程序不再崩溃.

I have been trying to debug a crash in my application that crashes (i.e. asserts a * glibc detected * free(): invalid pointer: 0x000000000070f0c0 ***) while I'm trying to do a simple assign to a string. Note that I'm compiling on a linux system with gcc 4.2.4 with an optimization level set to -O2. With -O0 the application no longer crashes.

例如

std::string abc;

abc = "testString";

但如果我按如下方式更改代码，它就不再崩溃了

but if I changed the code as follows it no longer crashes 

std::string abc("testString");

所以我又挠了挠头！但有趣的模式是，崩溃在应用程序中稍后移动，AGAIN 在另一个字符串处.我发现应用程序在字符串分配上不断崩溃，这很奇怪.典型的崩溃回溯如下所示:

So again I scratched my head! But the interesting pattern was that the crash moved later on in the application, AGAIN at another string. I found it weird that the application was continuously crashing on a string assign. A typical crash backtrace would look as follows:

#0  0x00007f2c2663bfb5 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00007f2c2663bfb5 in raise () from /lib64/libc.so.6
#1  0x00007f2c2663dbc3 in abort () from /lib64/libc.so.6
#2  0x00000000004d8cb7 in people_streamingserver_sighandler (signum=6) at src/peoplestreamingserver.cpp:487
#3  <signal handler called>
#4  0x00007f2c2663bfb5 in raise () from /lib64/libc.so.6
#5  0x00007f2c2663dbc3 in abort () from /lib64/libc.so.6
#6  0x00007f2c26680ce0 in ?? () from /lib64/libc.so.6
#7  0x00007f2c270ca7a0 in std::string::assign (this=0x7f2c21bc8d20, __str=<value optimized out>)
    at /home/bbazso/ThirdParty/sources/gcc-4.2.4/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:238
#8  0x00007f2c21bd874a in PEOPLESProtocol::GetStreamName (this=<value optimized out>,
    pRawPath=0x2342fd8 "rtmp://127.0.0.1/mp4:pop.mp4", lStreamName=@0x7f2c21bc8d20)
    at /opt/trx-HEAD/gcc/4.2.4/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../include/c++/4.2.4/bits/basic_string.h:491
#9  0x00007f2c21bd9daa in PEOPLESProtocol::SignalProtocolCreated (pProtocol=0x233a4e0, customParameters=@0x7f2c21bc8de0)
    at peoplestreamer/src/peoplesprotocol.cpp:240

这确实是一种奇怪的行为，因此我开始在我的应用程序中进一步查看是否存在某种可能导致这种奇怪行为的内存损坏(堆或堆栈)错误.我什至检查了 ptr 损坏并空手而归.除了对代码进行视觉检查之外，我还尝试了以下工具:

This was really weird behavior and so I started to poke around further in my application to see if there was some sort of memory corruption (either heap or stack) error that could be occurring that could be causing this weird behavior. I even checked for ptr corruptions and came up empty handed. In addition to visual inspection of the code I also tried the following tools:

  • 同时使用 memcheck 和 exp-ptrcheck 的 Valgrind
  • 电围栏
  • 库安全
  • 我在 gcc 中使用 -fstack-protector-all 编译
  • 我尝试将 MALLOC_CHECK_ 设置为 2
  • 我通过 lint 检查和 cppcheck(检查错误)运行我的代码
  • 我使用 gdb 逐步完成了代码

所以我尝试了很多东西，但仍然空手而归.所以我想知道它是否可能是链接器问题或某种可能导致此问题的库问题.std::string 是否存在任何已知问题，使得 make 容易在 -O2 中崩溃，或者它可能与优化级别无关?但是到目前为止，我在我的问题中可以看到的唯一模式是它似乎总是在字符串上崩溃，所以我想知道是否有人知道我导致这种行为的任何问题.

So I tried a lot of stuff and still came up empty handed. So I was wondering if it could be something like a linker issue or a library issue of some sort that could be causing this problem. Are there any know issues with the std::string that make is susceptible to crashing in -O2 or maybe it has nothing to do with the optimization level? But the only pattern that I can see thus far in my problem is that it always seems to crash on a string and so I was wondering if anyone knew of any issues that my be causing this type of behavior.

非常感谢！

推荐答案

这是使用我可以从您的回溯中提取的所有信息进行的初步猜测.

This is an initial guess using all information I can extract from your back trace.

您很可能混合和匹配 gcc 版本、链接器和 libstdc++，导致主机上出现异常行为:

You are most likely mixing and matching gcc version, linker and libstdc++ that results an unusual behaviour on the host machine:

  1. libc 是系统的:/lib64/libc.so.6
  2. libstdc++ 位于ThirdParty"目录中 - 这是怀疑，因为它告诉我它可能会在其他地方用不同的目标编译 - /home/bbazso/ThirdParty/sources/gcc-4.2.4/x86_64-pc-linux-gnu/libstdc++-v3/
  3. /opt 中的另一个 libstdc++:/opt/trx-HEAD/gcc/4.2.4/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../include/c++/4.2.4/bits/basic_string.h:491
  1. libc is the system's: /lib64/libc.so.6
  2. libstdc++ is in a "ThirdParty" directory - this is suspicions, as it tells me it might be compiled elsewhere with a different target - /home/bbazso/ThirdParty/sources/gcc-4.2.4/x86_64-pc-linux-gnu/libstdc++-v3/
  3. Yet another libstdc++ in /opt: /opt/trx-HEAD/gcc/4.2.4/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../include/c++/4.2.4/bits/basic_string.h:491

此外，GCC 可能会混合系统的 ld 而不是自身，这可能会导致更奇怪的内存映射使用.

In addition, GCC may mix the system's ld instead of itself which may cause further weird memory maps usage.

相关文章