2

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

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* 成员。这在该类型的析构函数中被删除并为空。构造函数使用 m_pData = new std::wstring( ( (std::wstring )source.m_pData) ); 对于字符串。（其他数据类型也类似）。这可能是个问题吗？(删除 static_cast< std::wstring* >( m_pData );)

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

4

2 回答 2

2

终于找到错误了。

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

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

两天的调试把'%'改成'/'。

不过感谢大家的支持。

于 2010-01-19T15:34:07.517 回答
0

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

于 2010-01-18T22:24:58.477 回答