C++执行 std::string 分配时程序总是崩溃
我一直在尝试调试我的应用程序中崩溃的崩溃(即断言 * glibc detectors * free(): invalid point: 0x000000000070f0c0 ***) 当我尝试对字符串进行简单分配时。请注意,我正在使用 gcc 4.2.4 的 Linux 系统上进行编译,优化级别设置为 -O2。使用 -O0,应用程序不再崩溃。
例如,
std::string abc;
abc = "testString";
但如果我按如下方式更改代码,它就不再崩溃
std::string abc("testString");
所以我再次抓破了头!但有趣的模式是,崩溃后来在应用程序中发生,再次发生在另一个字符串上。我发现应用程序在字符串分配时不断崩溃很奇怪。典型的崩溃回溯如下所示:
#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 损坏情况,却空手而归。除了对代码进行目视检查之外,我还尝试了以下工具:
- Valgrind 使用 memcheck 和 exp-ptrcheck
- 电围栏
- libsafe
- 我在 gcc 中使用 -fstack-protector-all 进行编译
- 我尝试将 MALLOC_CHECK_ 设置为 2
- 我通过 lint 检查运行我的代码以及 cppcheck (检查错误)
- 我使用 gdb 逐步完成了代码
所以我尝试了很多东西,但仍然空手而归。所以我想知道是否可能是链接器问题或某种库问题导致了这个问题。 std::string 是否存在任何已知问题,使得 make 容易在 -O2 中崩溃,或者可能与优化级别无关?但到目前为止,我在问题中看到的唯一模式是它似乎总是在字符串上崩溃,所以我想知道是否有人知道我导致这种行为的任何问题。
多谢!
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.
E.g.
std::string abc;
abc = "testString";
but if I changed the code as follows it no longer crashes
std::string abc("testString");
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
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 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
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.
Thanks a lot!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
这是使用我可以从您的回溯中提取的所有信息进行的初步猜测。
您很可能混合和匹配 gcc 版本、链接器和 libstdc++,导致主机上出现异常行为:
/lib64/libc.so.6
/home/bbazso/ThirdParty/sources/gcc-4.2.4/x86_64-pc-linux-gnu/libstdc++-v3/
/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
此外,GCC 可能会混合系统的 ld 而不是它本身,这可能会导致进一步奇怪的内存映射用法。
This is an initial guess using all information I can extract from your back trace.
You are most likely mixing and matching gcc version, linker and libstdc++ that results an unusual behaviour on the host machine:
/lib64/libc.so.6
/home/bbazso/ThirdParty/sources/gcc-4.2.4/x86_64-pc-linux-gnu/libstdc++-v3/
/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
In addition, GCC may mix the system's ld instead of itself which may cause further weird memory maps usage.
你能用一个基本的两行程序重复崩溃吗?
如果崩溃,请发布您确切的编译/链接选项?
如果没有,请开始削减您的代码。一次只删除几行,直到错误消失。一旦您进行了一些其他更改,您可以添加以导致崩溃并删除以使其消失,这应该可以帮助您找到问题。
Can you repeat the crash with a basic two line program?
If that crashes, please post your exact compile / link options?
If not, start paring down your code. Remove things lines a handful at a time until the bug goes away. Once you have some other change you can add to cause the crash and remove to make it go away, that should help you locate the problem.
发生在我身上是因为对一个以 std::strings 作为数据成员的类使用 malloc 。棘手。
Happened to me because of using malloc for a class which had std::strings as data members. Tricky.
正如你所说,这是一种奇怪的行为。
老实说,我认为您正在浪费时间研究 std::strings 可能存在的错误。只要使用得当,琴弦是绝对安全的。
无论如何,根据您提供的信息:
首先,你使用线程吗?可能是线程问题。
其次,使用 valgrind 检查程序。你们完全没有警告吗?
注意:最关键的 valgrind 警告是无效读取和无效写入。
PS:正如评论中所说,您可能应该使用 g++ 来编译 C++ 代码;)
As you said it's a weird behavior.
To be honnest with i think you are wasting time looking into a possible bug with std::strings. Strings are perfectly safe as long as you are using them well.
Anyway, with the informations you are giving :
First, are you using threads ? It's might be a thread problem.
Second, you check your program using valgrind. Have you no warnings at all ?
Note : The most critical valgrind's warnings are invalid read and invalid write.
PS : As said in commentary, you should probably use g++ to compile C++ code ;)