在堆栈上创建对象之前可以展开对象吗？

Question

我们已经调试一个奇怪的案例几天了，并在一定程度上隔离了该错误，但它仍然没有任何意义。也许这里的任何人都可以告诉我发生了什么事。

问题是部分代码中发生了访问冲突。

基本上我们有这样的东西：

void aclass::somefunc() {
  try {
    erroneous_member_function(*someptr);
  } 
  catch (AnException) {
  }
}

void aclass::erroneous_member_function(const SomeObject& ref) {
  // { //<--scope here error goes away
  LargeObject obj = Singleton()->Object.someLargeObj; //<-remove this error goes away

  //DummyDestruct dummy1//<-- this is not destroyed before the unreachable

  throw AnException();

  // } //<--end scope here error goes away 

  UnreachableClass unreachable; //<- remove this, and the error goes away

  DummyDestruct dummy2; //<- destructor of this object is called! 
}

在调试器中，它实际上看起来像是在破坏 UnreachableClass，并且当我插入 DummyDestruct 对象时，在调用奇怪的析构函数之前，它不会被破坏。因此，LargeObject 的销毁似乎并没有出现问题。

所有这些都在生产代码中，很难将其隔离到一个小示例中。

我的问题是，有谁知道造成这种情况的原因以及正在发生的事情吗？我有一个功能相当齐全的调试器（Embarcadero RAD studio），但现在我不知道该怎么用它。

谁能给我一些关于如何进行的建议？

更新：

我在 throw 子句下放置了一个 DummyDestruct 对象，并在析构函数中放置了一个断点。输入该对象的析构函数（并且它唯一的我们就在这段代码中）。

Answer 1

根据您提供的信息，如果一切都如您所述，唯一可能的答案是编译器/优化器中的错误。只需添加额外的范围和注释（这也是，如果一切都与您所说的完全一样）。

Answer 2

有时，由于通过未初始化的指针进行写入、越界数组访问等，会发生类似的情况。引起错误的点可能与它出现的位置相去甚远。但是，根据您描述的症状，它似乎局限于此功能。 LargeObject 的复制构造函数是否行为不当？正在使用 ref 吗？也许 somePtr 没有指向有效的 SomeObject。 Singleton() 是否返回指向有效对象的指针？
编译器错误也是有可能的，尤其是在打开积极优化的情况下。我会尝试在不进行优化的情况下重新创建该错误。

Answer 3

是时候练习我的心灵感应调试技能了：

我最好的猜测是您的应用程序存在堆栈损坏错误。这可能会在调用堆栈上写入垃圾，这意味着调试器在中断时错误地报告该函数，并且它实际上并不在析构函数中。要么是您错误地解释了调试器的信息，并且对象确实被正确破坏，但您不知道为什么！

如果出现堆栈损坏的情况，您将很难找出根本原因。这就是为什么在整个程序中实现大量诊断（例如断言）非常重要，这样您就可以在发生堆栈损坏时捕获它，而不是陷入其奇怪的副作用中。

Answer 4

这可能是一个真正的远景，但无论如何我都会把它放在那里......

你说你使用 borland - 什么版本？你说你看到了字符串中的错误 - STL？你的项目中是否包含了winsock2？

我问的原因是我在使用 borland 6 (2002) 和 Winsock 时遇到了问题 - 标头似乎搞乱了结构打包，并且意味着不同的翻译单元对 std::string 的内存布局有不同的想法，具体取决于翻译单元包含了哪些标头，这会带来可预见的灾难性结果。

Answer 5

自从你提到字符串以来，这是另一个疯狂的猜测。我知道至少有一种实现，其中（STL）字符串复制是以惰性方式完成的（即，在进行更改之前不会实际复制字符串内容；“复制”是通过简单地拥有目标字符串对象来完成的指向与源相同的缓冲区）。在该特定实现 (GNU) 中存在一个错误，过度复制会导致引用计数器（在复制后有多少对象正在使用相同的实际字符串内存）翻转到 0，从而导致各种恶作剧。我自己没有遇到过这个错误，但是有人告诉过我这个错误。 （我这样说是因为人们会认为参考计数器将是一个 32 位数字，并且至少可以说，翻转的可能性非常小，所以我可能没有正确描述问题。）