Question

我在以下简化代码中遇到内存分配错误（以及随后的崩溃）：

std::wstring myKey = L"str_not_actually_constant";

MyType obj;
Read( obj );

std::map<std::wstring, MyType> myMap;
myMap[myKey] = obj; // Sometimes allocation error (1)
...
Read( MyType& obj )
{
  obj.member1 = ReadFromFuncThatMayBeProblem();
  obj.member2 = ReadFromFuncThatMayBeProblem(); // Sometimes allocation error (2)
  /* more members */
}
...
void operator =( const MyType& source )
{
  if( this != &source )
  {
    member1 = source.member1; // std::wstring
    member2 = source.member2; // Usually (1) happen on the second member. // std::wstring
    /* more members */
  }
}

发生（1）或（2）。

现在，如果我继续操作而不管错误（使用调试器），那么该值确实会输入到地图中。

我不知道ReadFromFuncThatMayBeProblem（）是否是罪魁祸首，但它是一个相当复杂的功能，我不能在这里放纵。

此外，这是在应用程序的其他部分移植到使用OpenSSL之前已经工作（或至少看起来有效）的代码。不过，我不知道这是否会产生任何影响。

那么，我可以做些什么来追踪这个分配错误，因为我假设上面的代码实际上并不是问题？

编辑：更多信息： MyType没有dtor。

但是，MyType具有SecondType类型的成员，该成员具有void *成员。这被删除并在该类型的析构函数中为null。构造函数使用m_pData = new std :: wstring（（（std :: wstring ）source.m_pData））;对于字符串。（和其他数据类型类似）。这可能是个问题吗？（删除static_cast＆lt; std :: wstring *＆gt;（m_pData）;）

MyType的其他成员类型是std :: wstring，unsigned long，bool，enum，structs（其中包括timeb）和SecondType。

Answer 1

最后追踪错误。

我们使用上述功能作为使用OpenSSL的更大套接字通信的一部分（因此参考上面）。根据上述代码简化，套接字正在写入数据和读取数据。

读取套接字的方式是我们将内存从一个缓冲区重新分配给另一个缓冲区（动态地改变大小）。在这样做时，我们使用缓冲区的输入和我们应该扩展的大小。尺寸计算使用模数来计算重新尺寸的因子。这导致缓冲区太大或太小而不适合以下操作。

两天的调试将'％'更改为'/'。

感谢所有支持。

Answer 2

ReadFromFuncThatMayBeProblem（）返回什么类型？它是否返回（const）引用？如果是这样，在离开ReadFromFuncThatMayBeProblem（）范围后对象是否仍然有效？

查找内存分配错误

2 个答案: