Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. Memory Leak

Memory Leak

Scheduled Pinned Locked Moved C / C++ / MFC
c++comperformancequestionannouncement
5 Posts 4 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • W Offline
    W Offline
    William Bartholomew
    wrote on last edited by
    #1

    I have the following piece of code in an ATL COM component that I have developed. What this piece of code does is create a COM instance of another object inside the same COM component. However, somewhere in this piece of code is a memory leak. I have tested the COM object that is being created here seperately and it does not have a leak so it must be somewhere in this creation/destruction code... could anyone please let me know if they see something glaringly wrong? Thanks. // Calculate the checksum HRESULT hr = NULL; IHash *IHash = NULL; // Now we will intilize COM hr = CoInitialize( 0 ); // Use the SUCCEEDED macro and see if we can get a pointer // to the interface if ( SUCCEEDED( hr ) ) { hr = CoCreateInstance( CLSID_Hash, NULL, CLSCTX_INPROC_SERVER, IID_IHash, (void**)&IHash ); if ( SUCCEEDED( hr ) ) { BSTR* szReturn = new BSTR; IHash->Digest( szTemp.m_str, szReturn ); IHash->Release(); szTemp.AppendBSTR( *szReturn ); delete szReturn; } }

    G M L 4 Replies Last reply
    0
    • W William Bartholomew

      I have the following piece of code in an ATL COM component that I have developed. What this piece of code does is create a COM instance of another object inside the same COM component. However, somewhere in this piece of code is a memory leak. I have tested the COM object that is being created here seperately and it does not have a leak so it must be somewhere in this creation/destruction code... could anyone please let me know if they see something glaringly wrong? Thanks. // Calculate the checksum HRESULT hr = NULL; IHash *IHash = NULL; // Now we will intilize COM hr = CoInitialize( 0 ); // Use the SUCCEEDED macro and see if we can get a pointer // to the interface if ( SUCCEEDED( hr ) ) { hr = CoCreateInstance( CLSID_Hash, NULL, CLSCTX_INPROC_SERVER, IID_IHash, (void**)&IHash ); if ( SUCCEEDED( hr ) ) { BSTR* szReturn = new BSTR; IHash->Digest( szTemp.m_str, szReturn ); IHash->Release(); szTemp.AppendBSTR( *szReturn ); delete szReturn; } }

      G Offline
      G Offline
      Gerald Schwab
      wrote on last edited by
      #2

      I didn't think you could create BSTR's this way. I think you have to call SysAllocString(). Or could it be that you are not freeing your BSTR? Just a guess....

      1 Reply Last reply
      0
      • W William Bartholomew

        I have the following piece of code in an ATL COM component that I have developed. What this piece of code does is create a COM instance of another object inside the same COM component. However, somewhere in this piece of code is a memory leak. I have tested the COM object that is being created here seperately and it does not have a leak so it must be somewhere in this creation/destruction code... could anyone please let me know if they see something glaringly wrong? Thanks. // Calculate the checksum HRESULT hr = NULL; IHash *IHash = NULL; // Now we will intilize COM hr = CoInitialize( 0 ); // Use the SUCCEEDED macro and see if we can get a pointer // to the interface if ( SUCCEEDED( hr ) ) { hr = CoCreateInstance( CLSID_Hash, NULL, CLSCTX_INPROC_SERVER, IID_IHash, (void**)&IHash ); if ( SUCCEEDED( hr ) ) { BSTR* szReturn = new BSTR; IHash->Digest( szTemp.m_str, szReturn ); IHash->Release(); szTemp.AppendBSTR( *szReturn ); delete szReturn; } }

        M Offline
        M Offline
        Michael Dunn
        wrote on last edited by
        #3

        You're handling your BSTRs wrong. When a method returns a string through a BSTR*, you pass the address of a BSTR, not a BSTR* (if that makes sense). :)

        BSTR bsReturn;
        ...
        IHash->Digest ( szTemp.m_str, &bsReturn );
        ...
        SysFreeString ( bsReturn );

        You can also use CComBSTR or _bstr_t which do the memory management for you. --Mike-- http://home.inreach.com/mdunn/ The Signature, back by popular demand: Buffy. Pajamas.

        1 Reply Last reply
        0
        • W William Bartholomew

          I have the following piece of code in an ATL COM component that I have developed. What this piece of code does is create a COM instance of another object inside the same COM component. However, somewhere in this piece of code is a memory leak. I have tested the COM object that is being created here seperately and it does not have a leak so it must be somewhere in this creation/destruction code... could anyone please let me know if they see something glaringly wrong? Thanks. // Calculate the checksum HRESULT hr = NULL; IHash *IHash = NULL; // Now we will intilize COM hr = CoInitialize( 0 ); // Use the SUCCEEDED macro and see if we can get a pointer // to the interface if ( SUCCEEDED( hr ) ) { hr = CoCreateInstance( CLSID_Hash, NULL, CLSCTX_INPROC_SERVER, IID_IHash, (void**)&IHash ); if ( SUCCEEDED( hr ) ) { BSTR* szReturn = new BSTR; IHash->Digest( szTemp.m_str, szReturn ); IHash->Release(); szTemp.AppendBSTR( *szReturn ); delete szReturn; } }

          L Offline
          L Offline
          Lost User
          wrote on last edited by
          #4

          Generally BSTR creates memory leak.Hence in order to avoid it use either _bstr_t or CComBstr. And even instead of BSTR* use BSTR object and pass the address to the function. And free it through SysFreeString function. BSTR m_bstr; IHash->Digest(szTemp.m_str, &m_bstr); ... .. SysFreeString(m_bstr);;P ;P :p

          1 Reply Last reply
          0
          • W William Bartholomew

            I have the following piece of code in an ATL COM component that I have developed. What this piece of code does is create a COM instance of another object inside the same COM component. However, somewhere in this piece of code is a memory leak. I have tested the COM object that is being created here seperately and it does not have a leak so it must be somewhere in this creation/destruction code... could anyone please let me know if they see something glaringly wrong? Thanks. // Calculate the checksum HRESULT hr = NULL; IHash *IHash = NULL; // Now we will intilize COM hr = CoInitialize( 0 ); // Use the SUCCEEDED macro and see if we can get a pointer // to the interface if ( SUCCEEDED( hr ) ) { hr = CoCreateInstance( CLSID_Hash, NULL, CLSCTX_INPROC_SERVER, IID_IHash, (void**)&IHash ); if ( SUCCEEDED( hr ) ) { BSTR* szReturn = new BSTR; IHash->Digest( szTemp.m_str, szReturn ); IHash->Release(); szTemp.AppendBSTR( *szReturn ); delete szReturn; } }

            L Offline
            L Offline
            Lost User
            wrote on last edited by
            #5

            Generally BSTR creates memory leak.Hence in order to avoid it use either _bstr_t or CComBstr. And even instead of BSTR* use BSTR object and pass the address to the function. And free it through SysFreeString function. BSTR m_bstr; IHash->Digest(szTemp.m_str, &m_bstr); ... .. SysFreeString(m_bstr);;P ;P :p

            1 Reply Last reply
            0
            Reply
            • Reply as topic
            Log in to reply
            • Oldest to Newest
            • Newest to Oldest
            • Most Votes


            • Login

            • Don't have an account? Register

            • Login or register to search.
            • First post
              Last post
            0
            • Categories
            • Recent
            • Tags
            • Popular
            • World
            • Users
            • Groups