このC++のメモリリークはどこにありますか？

Question

私は次のコードは、メモリをリークしているツールのカップルも言われているが、どこ私たちは私たちの生活のために見ることができない：私たちは、OLEVARバリアントとは何かであると仮定

HRESULT CDatabaseValues::GetCStringField(ADODB::_RecordsetPtr& aRecordset, CString& strFieldValue, 
             const char* strFieldName, const bool& bNullAllowed) 
{ 
    HRESULT hr = E_FAIL; 

    try 
    { 
     COleVariant olevar; 
     olevar = aRecordset->Fields->GetItem(_bstr_t(strFieldName))->Value; 
     if (olevar.vt == VT_BSTR && olevar.vt != VT_EMPTY) 
     { 
      strFieldValue = olevar.bstrVal; 
      hr = true; 
     } 
     else if ((olevar.vt == VT_NULL || olevar.vt == VT_EMPTY) && bNullAllowed) 
     { 
      //ok, but still did not retrieve a field 
      hr = S_OK; 
      strFieldValue = ""; 
     } 
    } 
    catch(Exception^ error) 
    { 
     hr = E_FAIL; 
     MLogger::Write(error); 
    } 
    return hr; 
} 

リークのサイズがレコードセットから返される文字列のサイズと一致するためです。

olevar.detach（）とolevar.clear（）はどちらも効果がありませんでした。これが原因であれば、おそらくGetItemに割り当てられているメモリを解放します。そして、これが原因でないなら、何がありますか？

EDIT

私はレイによって提案された記事を読み、またそれに関連するコメントや、その後試してみました：olevariantとBSTRいる

HRESULT CDatabaseValues::GetCStringField(ADODB::_RecordsetPtr& aRecordset, CString& strFieldValue, 
             const char* strFieldName, const bool& bNullAllowed) 
{ 
    HRESULT hr = E_FAIL; 

    try 
    { 
     COleVariant* olevar = new COleVariant(); 
     _bstr_t* fieldName = new _bstr_t(strFieldName); 
     *olevar = aRecordset->Fields->GetItem(*fieldName)->Value; 
     if (olevar->vt == VT_BSTR && olevar->vt != VT_EMPTY) 
     { 
      strFieldValue = olevar->bstrVal; 
      hr = true; 
     } 
     else if ((olevar->vt == VT_NULL || olevar->vt == VT_EMPTY) && bNullAllowed) 
     { 
      //ok, but still did not retrieve a field 
      hr = S_OK; 
      strFieldValue = ""; 
     } 
     delete olevar; 
     delete fieldName; 
    } 
    catch(Exception^ error) 
    { 
     hr = E_FAIL; 
     MLogger::Write(error); 
    } 
    return hr; 
} 

主な違いは、現在、明示的に作成および破棄されます。

これはリークの量を約半分にしましたが、ここに漏れているものがまだあります。

解決策？デタッチの使用についてのレイからアドバイスを見てみると

は、私はこの思い付いたん：

HRESULT CDatabaseValues::GetCStringField(ADODB::_RecordsetPtr& aRecordset, CString& strFieldValue, 
             const char* strFieldName, const bool& bNullAllowed) 
{ 
    HRESULT hr = E_FAIL; 

    try 
    { 
     COleVariant olevar; 
     _bstr_t fieldName = strFieldName; 
     olevar = aRecordset->Fields->GetItem(fieldName)->Value; 

     if (olevar.vt == VT_BSTR && olevar.vt != VT_EMPTY) 
     { 
      BSTR fieldValue = olevar.Detach().bstrVal; 
      strFieldValue = fieldValue; 
      ::SysFreeString(fieldValue); 
      hr = true; 
     } 
     else if ((olevar.vt == VT_NULL || olevar.vt == VT_EMPTY) && bNullAllowed) 
     { 
      //ok, but still did not retrieve a field 
      hr = S_OK; 
      strFieldValue = ""; 
     } 
     ::SysFreeString(fieldName); 
    } 
    catch(Exception^ error) 
    { 
     hr = E_FAIL; 
     MLogger::Write(error); 
    } 
    return hr; 
} 

ツール（GlowCode）によれば、これはもはやリークしているが、私はfieldValueの上SysFreeStringのを使用して心配ですそれがCStringに割り当てられた後。それは実行されるように見えますが、私はそれが記憶腐敗が無料であるという指標ではないことを知っています！

Answer 1

BSTRに割り当てられたメモリを解放する必要があります。

はarticle

ああを参照してください、あなたはCStringの

に

strFieldValue = olevar.detach().bstrVal; 

をVARIANTのBSTR値を割り当てる前に切り離しを行い、その後、あなたのCStringオブジェクトが正しく時間内に破壊されますことを確認する必要があります。

Answer 2

このコードスニペットでは、例外ハンドラのメモリがリークする可能性があります。言い換えると、この関数は例外的に安全ではありません。

catch(Exception^ error) 
{ 
    hr = E_FAIL; 
    MLogger::Write(error); 
} 

あなたは、あなたがdeleteラインに到達する前にnewとを呼び出した後、例外がスローされた場合にolevarまたはfieldNameをクリーンアップすることはありません。

スマートポインタ（std::auto_ptr、boost::scoped_ptr）を使用して、ポインタの使用を終了すると自動的にポインタを解放することをお勧めします。

std::auto_ptr<COleVariant> olevar(new COleVariant);