Question

这一定是我做了一些愚蠢的事情，但之前有人见过这种行为：

我在类成员中有一个映射，如下所示：

std::map <const std::string, int> m_fCurveMap;

所有在调试中表现都很好但在发布模式下都出错了。 map初始化为一些疯狂的数字：m_fCurveMap [14757395258967641292]()

我在地图后遇到的任何成员都被完全破坏了，即如果我在地图之后的行上放置一个int，就像这样：

std::map <const std::string, int> m_fCurveMap;
int m_myIntThing;

并且在我的构造函数中将m_myIntThing设置为0，在构造函数被调用之后m_myIntThing是一些疯狂的数字。如果我将m_myIntThing移动到地图上方的行，m_myIntThing的所有内容都可以。这最终会给我带来很大的问题。我是否需要在构造函数中对地图执行某些操作？我现在不在。

我正在使用visual studio，这与gcc一起工作正常。我只看到发布中的问题。这个项目是一个dll。

如果你之前看到过这种疯狂，请帮助它让我发疯。： - ）

非常感谢，标记

Answer 1

很多次发生在我身上。虽然在您的情况下很难说，但很可能的原因是您在不同项目之间有不同版本的C运行时库。检查您的不同项目的编译器设置中的“代码生成”选项卡，并确保它们是相同的。

实际发生的是不同版本的C运行时库以不同方式实现STL容器。然后，当不同的项目试图互相交谈时，std :: map的含义（例如）已经改变，并且不再是二进制兼容的。

奇怪的行为很可能是某种堆损坏，或者如果它作为参数传递给函数，则堆栈损坏。

Answer 2

问题在于某种内存损坏。

我在C ++项目中经常看到的一个错误是在删除对象后使用它。

另一种可能性是缓冲区溢出。它可以是同一堆栈上或堆上附近的任何对象。

捕获罪魁祸首的一个很好的方法是设置一个调试器断点，触发内存更改。虽然对象仍然很好，但设置断点。然后等到某些代码写入该内存位置。这应该揭示你的错误。

Answer 3

如果您从VS调试器获取信息，我不相信它告诉您的Release DLL。调试器只能真正受调试DLL的支持。

如果程序输出告诉你这个，那就不一样了 - 在这种情况下，你没有提供足够的信息。

Answer 4

您是否正在将发布DLL与调试应用混合使用？

否则听起来像是内存损坏，虽然我不能肯定地说。

在某些情况下，其中任何一种都可能正常工作，因为它们是未定义的行为，只有在发布模式下它们才会爆炸。

Answer 5

我在g ++上遇到了完全相同的问题，我在此之前通过删除pragma段落中的pragma来解决它。尽管代码是正确的，我想知道在某些情况下使用stl :: map时这是否是平台上的编译器错误。

#pragma pack(push,1)
xxxx
#pragma(pop)

Answer 6

举一个具体的内存损坏示例：

org.osgi.framework.bootdelegation

无意中，我将ref定义为成员变量而不是成员变量本身。它初始化正常，但是一旦static_init（）的范围被保留，地图就会被销毁，并且ref将在调试中显示为“std :: map with 140737305218461 elements”（漂亮打印）或类似的指向现在未分配的meory（或更糟）。

谨防意外参考！