C++程序总是在执行std :: string赋值时崩溃

bba*_*zso 11 c++ crash gdb valgrind stdstring

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

例如

std::string abc;

abc = "testString";
Run Code Online (Sandbox Code Playgroud)

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

std::string abc("testString");
Run Code Online (Sandbox Code Playgroud)

所以我再次挠挠脑袋!但有趣的模式是,崩溃后来在应用程序中移动,AGAIN在另一个字符串.我发现应用程序在字符串赋值上不断崩溃是很奇怪的.典型的崩溃回溯看起来如下:

#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
Run Code Online (Sandbox Code Playgroud)

这真是奇怪的行为,所以我开始在我的应用程序中进一步探讨是否存在某种可能导致这种奇怪行为的内存损坏(堆或堆栈)错误.我甚至检查了ptr腐败并空手而归.除了对代码进行目视检查外,我还尝试了以下工具:

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

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

非常感谢!

Lir*_*una 10

这是使用我可以从后面跟踪中提取的所有信息的初始猜测.

您最有可能混合和匹配gcc版本,链接器和libstdc ++,这会导致主机上出现异常行为:

  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

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

  • +1.有2个libstdc ++(但发生了这种情况)似乎很可能是问题的原因(或与原因有关).在使用GNU的std :: string实现时,我遇到了在DSO中传递std :: strings的问题(它对可能导致问题的空字符串进行了一些优化),而没有多个libstdc ++的额外复杂性. (3认同)

R S*_*hko 7

你能用基本的两线程序重复崩溃吗?

#include <string>

int main()
{
    std::string abc;
    abc = "testString";
}
Run Code Online (Sandbox Code Playgroud)

如果崩溃,请发布您的确切编译/链接选项?

如果没有,请开始削减您的代码.一次删除一些东西,直到bug消失.一旦你有其他一些变化,你可以添加导致崩溃并删除以使其消失,这应该可以帮助您找到问题.

  • @Tom - 好的,请接受我的下一个推荐.开始削减其余代码,直到分配不再崩溃. (2认同)