C SEG故障在STD :: String Destructor上，仅当传递变量时

Question

这个问题发生在许多繁忙功能的中间，因此我将尝试解释伪代码的问题，希望它足够了。我同样有兴趣理解潜在问题与解决问题一样，因此除了修复外，我还要感谢解释。谢谢！

'MethodOne'从另一个函数中检索std :: String XX，并将其与字符串X1，X2和X3（全部从新对象）一起发送到'MethodTwo'。

bool methodOne(...) {
    Object1 obj = Object1(...);
    string xx = obj.someFunction(...);
    methodTwo(xx, obj.getX1(), obj.getX2(), obj.getX3() );
    ...
    return true;
}

'methodtwo'（在object2中）然后将这些字符串结合到向量中，然后将它们传递到'MethodThree'。

bool Object2::methodTwo(const string xx, const string x1, const string x2, const string x3) {
   vector<string> holder;      // alternate - comment out this line
   holder.push_back(xx);       //             and this line,
   // vector<string> holder(1, "test");    // alternate - uncomment this line
   holder.push_back(x1);
   holder.push_back(x2);
   holder.push_back(x3);
   ...
   obj3.methodThree( holder );
   ...
   return true;
}          // line 443 - where error is backtraced to

最后，'methodthree'最终创建一些文件，所有四个字符串均打印到其中一个。

运行程序，我从GDB中得到一个细分错误：

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000 0x00007fff8f1e3aa2 in std::basic_string<char, std::char_traits<char>, std::allocator<char>
>::~basic_string () (gdb) where
#0  0x00007fff8f1e3aa2 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string ()
#1  0x0000000100009f18 in std::_Destroy<std::string> ()
#2  0x0000000100009f3e in std::__destroy_aux<std::string*> ()
#3  0x0000000100009f9f in std::_Destroy<std::string*> ()
#4  0x0000000100009fd7 in std::_Destroy<std::string*, std::string> ()
#5  0x0000000100060115 in std::vector<std::string, std::allocator<std::string> >::~vector (this=0x7fff5fbfd488) at stl_vector.h:271
#6  0x0000000100013b9f in Station::methodTwo (this=0x7fff5fbff110, foreFN=@0x7fff5fbfdf08, startDT=@0x7fff5fbfded8, stopDT=@0x7fff5fbfdea8, numElems=169, tCase=0x7fff5fbfe7c8) at Station.cpp:443
#7  0x0000000100002b45 in methodOne ()
#8  0x000000010000707a in main ()

在'methodtwo'中，如果我用一些随机测试字符串替换字符串'xx'，则错误会消失。因此，问题必须是" xx" ---这也是" MethodOne"中唯一的字符串，它不是来自Object1 Obj。

我认为某些构造函数实际上并没有重复字符串（浅层复制该术语？），所以我尝试使用将methodwo调用为

之类的事情

methodTwo( string(xx), obj.getX1() ...)

或构造向量时，使用

之类的东西

holder.push_back( string(xx) );

，但这些事情都没有用。

我完全亏损了，我感谢任何人都有的帮助/提示。我知道这很烦人，因为我没有给出一个连贯的代码，可以重现问题，甚至可以重现实际的代码 - 但希望这足以让比我更明智的人看到某些东西。

谢谢

---

新的怪异：

从下面的评论中，听起来很可能实际错误在其他地方，从而感染了堆。但是，由于xx仅通过不是从obj检索到的区分，所以我尝试将xx添加到对象中---即，在另一种方法中，在另一种方法中，变量xx设置为同一事物，将其设置为同一thics值，将结果设置为相同的值为应该以前...

string Object1::someFunction(...) {
    ...
    string val = ...;
    setXX(val);
    cout << getXX() << endl;         // this *correctly* prints the value of xx
    ...
    return val;
}
void Object1::setXX(string temp) { xx = string(temp); }
string Object1::getXX() { return xx; }

然后我在methodTwo呼叫中检索XX：

methodTwo(obj.getXX(), obj.getX1() ... );

停止了错误，但是 xx 不会存储字符串！

obj.someFunction(...);          // this is able to set and retrieve xx
cout << obj.getXX() << endl;    //  prints **blank line!!**
methodTwo(obj.getXX(), obj.getX1() ...);   // no more error, x1 x2 x3 are fine, xx is empty!

现在我觉得我要疯了....

Answer 1

在内存分配器内崩溃时，很少会将问题跟踪到崩溃时释放（或分配）的确切内存。分配器将进行理智检查，通常会尝试释放无效的指针（指示的指针指向某些分配的开始，指针在堆的范围之外，重复的Frees等）。内存分配器中崩溃的最常见原因是堆损坏。通常，使用小块的小结构将释放的大块链接到其他自由块上。关于释放记忆或在分配的块之外写的写作会破坏这些指针并在分配器中造成崩溃。

我希望，如果您的备用程序程序在避免初次崩溃后运行了足够长的时间，则最终将再次发生崩溃。您使用xx观察到的模式可能很简单，就像xx的长度与x1一样大不相同。.x3，因此是从其他内存池分配的。

这是一个可以尝试的测试：如果您只是将return放在methodThree的顶部？