我正在调试核心转储,看起来我的应用程序在制作std :: string的副本时已经取得了核心。 sting的内容看起来有点破坏,因此崩溃是由于字符串在复制之前被破坏,或者是因为其他一些代码覆盖了部分字符串。是否有可能在gdb中判断字符串是否仍然存在(因此是否已覆盖其内存),或者字符串是否在复制之前被破坏了?
答案 0 :(得分:2)
如果你使用gcc中的gcc和std :: string(而不是来自STLport),那么std :: string中有一个内部结构,它包含_M_refcount,它在销毁后低于零(这里是俄语的详细解释)有一些数字"Несколько подробностей об std::string":
这是来自gcc 4.3.3的basic_string.h:
void
_M_dispose(const _Alloc& __a)
{
#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
if (__builtin_expect(this != &_S_empty_rep(), false))
#endif
if (__gnu_cxx::__exchange_and_add_dispatch(&this->_M_refcount,
-1) <= 0)
_M_destroy(__a);
} // XXX MT
~basic_string()
{ _M_rep()->_M_dispose(this->get_allocator()); }
所以这是一个简单的测试:
#include <string>
#include <stdio.h>
int main()
{
{
std::string s1("ABCDEFGHIJKLMNOPRSTUF1234567890");
printf("Before destruction\n");
}
return 0;
}
编译并构建:
g ++ -m64 -g -pthread main.cpp
这是在gdb下:
>gdb -q ./a.out
(gdb) start
Temporary breakpoint 1 at 0x400787: file main.cpp, line 7.
[Thread debugging using libthread_db enabled]
Temporary breakpoint 1, main () at main.cpp:7
7 std::string s1("ABCDEFGHIJKLMNOPRSTUF1234567890");
(gdb) n
8 printf("Before destruction\n");
(gdb) x/4gx (((void**)&s1)[0]-24)
0x601010: 0x000000000000001f 0x000000000000001f
0x601020: 0x0000000000000000 0x4847464544434241
(gdb) x/32c (((void**)&s1)[0])
0x601028: 65 'A' 66 'B' 67 'C' 68 'D' 69 'E' 70 'F' 71 'G' 72 'H'
0x601030: 73 'I' 74 'J' 75 'K' 76 'L' 77 'M' 78 'N' 79 'O' 80 'P'
0x601038: 82 'R' 83 'S' 84 'T' 85 'U' 70 'F' 49 '1' 50 '2' 51 '3'
0x601040: 52 '4' 53 '5' 54 '6' 55 '7' 56 '8' 57 '9' 48 '0' 0 '\000'
(gdb) n
Before destruction
10 return 0;
(gdb) x/4gx (((void**)&s1)[0]-24)
0x601010: 0x0000000000000000 0x000000000000001f
0x601020: 0x00000000ffffffff 0x4847464544434241
(gdb) x/32c (((void**)&s1)[0])
0x601028: 65 'A' 66 'B' 67 'C' 68 'D' 69 'E' 70 'F' 71 'G' 72 'H'
0x601030: 73 'I' 74 'J' 75 'K' 76 'L' 77 'M' 78 'N' 79 'O' 80 'P'
0x601038: 82 'R' 83 'S' 84 'T' 85 'U' 70 'F' 49 '1' 50 '2' 51 '3'
0x601040: 52 '4' 53 '5' 54 '6' 55 '7' 56 '8' 57 '9' 48 '0' 0 '\000'
正如破坏后所见,0x601020的值变为0x00000000ffffffff。 _M_refcount是四个字节长,因此在破坏后它是ffffffff(-1)。