C ++程序总是崩溃执行std :: string assign时 [英] C++ Program Always Crashes While doing a std::string assign

问题描述

我一直在试图调试崩溃在我的应用程序崩溃（即断言
* glibc检测到* free（）：无效指针：0x000000000070f0c0 ***） m试图做一个简单的分配到一个字符串。注意，我在一个linux系统上编译gcc 4.2.4，优化级别设置为-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:

• Valgrind使用memcheck和exp-ptrcheck


• 电子围栏


• libsafe


• 我用-fstack-protector-all编译gcc


• 我尝试将MALLOC_CHECK_设置为2


• 我通过lint检查以及cppcheck（检查错误）运行我的代码。


• 使用gdb遍历代码

• Valgrind using both memcheck and exp-ptrcheck
• electric fence
• libsafe
• I compiled with -fstack-protector-all in gcc
• I tried MALLOC_CHECK_ set to 2
• I ran my code through lint checks as well as cppcheck (to check for mistakes)
• And I stepped through the code using gdb

所以我尝试了很多东西，还是空手而归。所以我想知道，如果它可能是像一个链接器问题或库问题的某种可能是导致这个问题。有任何已知的问题，std ::字符串，使得容易崩溃-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. 另一个libstdc ++在 / 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

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.

这篇关于C ++程序总是崩溃执行std :: string assign时的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！