Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 411
  • Last Modified:

COM-Object - Memory leak ?

We have a COM-object developed in MSVCPP and want to use it in VBScript / ASP...

However we have the problem that there seems to be a memory leak, i.e. (my guess) probably reserved memory seems to be released before the result is available in the script. This would explan, why it works okay some times, crashes the server in other cases or gives weird results (strings that should not be there, but make sense in other scripts running on the webserver) in the third possible case...

The source (simplified):


STDMETHODIMP CDES::Encrypt(VARIANT HexMessage, VARIANT *HexCipher) {
        BYTE *RawCipher = NULL;
        int LenCipher;

        //... Believe me, there's code inbetween that makes sense ;) ...

        Byte2Var(RawCipher,LenCipher,*HexCipher);

     delete [] RawCipher;

     return S_OK;
}

void CDES::Byte2Var(BYTE *ByteIN, int Length, VARIANT &VarOUT) {
        BSTR OUTString = NULL;

     // This will put a string into OUTString
        Array2Hex(ByteIN, Length, OUTString);

        VarOUT = _variant_t(OUTString).Detach();
}



Then we call it...

     SET Encryption = CreateObject("DES.DES")
     MAC_out = Encryption.Encrypt(PutThisIn)                
     SET Encryption = Nothing


And there we get strange results...

Any hint/solution appreciated...
0
BlaM
Asked:
BlaM
  • 5
  • 2
1 Solution
 
skyDaemonCommented:
Never used vbscript, but I have done this in vb.

How do you feel about trading in your VARIANTS for BSTR's?  BSTR's are compatible with vb strings (I use them regularly for vb/vc++ dcom).  Presumably vbscript could handle it.  (It looks like you're using string types above anyway.)

Also, suggest you return the result as a parameter instead of a function result as you've got above.  I'm not certain, but this could be your problem by itself.  You might want to just change this first to see.

Here's a hardcoded example,

STDMETHODIMP CDES::Encrypt(BSTR HexMessage, BSTR* HexCipher, long* pnRes)
{
  CString str;
  str.Format("Hello World");

  *HexCipher = str.AllocSysString()

  *pnRes = S_OK;
  ...
}

Then in vb

Dim nSuccess as Long

nSuccess = Encryption.Encrypt(PutThisIn,GetThisBack)
               
Do update me on whether this does it.


0
 
BlaMAuthor Commented:
I believe that this might be the correct answer, because I also had the feeling that BSTR might be the better choice.

My main problem seems to be that this is the first time I have to work with COM-Objects and (additionally) I have to fix the code of one of my colleagues for whom it also was the first time to work with them ;)

This is how it now looks in my CPP-file:

STDMETHODIMP CDES::Encrypt(BSTR HexMessage, BSTR* HexCipher, long* pnRes) {
     _variant_t tempVarT;
     _bstr_t tempBstrT;

     tempVarT.SetString("Hello World");
     tempBstrT = tempVarT;
     *HexCipher = tempBstrT;

     *pnRes = S_OK;

     return 0;
}

(What do I return in your example? Anything?)

The function declaration now is

     STDMETHOD(Encrypt)(/*[in]*/ BSTR HexMessage, /*[out]*/ BSTR* HexMAC, /*[out, retval]*/ long *pnRes);

and finally there is another header file which contains

        virtual /* [helpstring][id] */ HRESULT STDMETHODCALLTYPE Encrypt(
            /* [in] */ BSTR HexMessage,
            /* [out] */ BSTR __RPC_FAR *HexMAC,
            /* [retval][out] */ long *pnRes) = 0;

(You'll probably notice that I have no idea about all that Windows-Development-stuff. I know C and C++ but ActiveX is a big questionmark of me ;)

In my VB Test-application the call looks like this:

    If o.Encrypt("01 02 03", tmp) = 0 Then
        Debug.Print tmp
    End If

I get the error message "Wrong number of arguments or invalid property assignment". Maybe something about the [] - Comments?
0
 
BlaMAuthor Commented:
Okay, to keep you updated:

When I remove the "return value" pnRes...

STDMETHODIMP CDES::MAC(BSTR HexMessage, BSTR* HexCipher)
{
     // convert pvBuffer to BSTR type
     _variant_t tempVarT;
     _bstr_t tempBstrT;

     tempVarT.SetString("Hello World");
     tempBstrT = tempVarT;
     *HexCipher = tempBstrT;
     ////////////////////////////////

     return S_OK;
}

... I now get the error message

Method '~' of Object '~' Failed

at the point where the values are returned...
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
skyDaemonCommented:
D'ohh, I had a nice answer typed up and it disappeared when I went to submit.  Here's the short version:

-The function declaration now is

STDMETHOD(Encrypt)(/*[in]*/ BSTR HexMessage, /*[out]*/ BSTR* HexMAC, /*[out, retval]*/ long *pnRes);

Change this to:

STDMETHOD(Encrypt)([in] BSTR HexMessage, [out] BSTR* HexMAC, [out, retval] long *pnRes);

Perhaps the compiler is defaulting your variables to [in] by default if it doesn't see the declaration because it's commented out?  That would mean it would expect 3 input variables from vb, thus your wrong number of arguments error.  Maybe....

-and finally there is another header file which contains

       virtual /* [helpstring][id] */ HRESULT STDMETHODCALLTYPE Encrypt(
           /* [in] */ BSTR HexMessage,
           /* [out] */ BSTR __RPC_FAR *HexMAC,
           /* [retval][out] */ long *pnRes) = 0;

That's an intermediate file generated by midl automatically I believe, you can ignore it.

-You do want to return ERROR_SUCCESS (equates to 0) and set *pnRes to whatever you want vb to see as a return code.  So if you return 0 and set *pnRes = 12, then o.Encrypt(x,y) = 12 in your vb app.  I think if you return -1 it'll throw a nasty generic automation error across the com boundary at your vb client.  Returning 0 is good.
0
 
BlaMAuthor Commented:
If I remove the comments it does not compile at all. "Syntax error".

I'm still at the task. I'll do some more experiments. ;)
0
 
BlaMAuthor Commented:
The problem seems to be that memory is allocated in the component, filled with content and at the point where I return to the main application the memory is released automatically, losing it's content when other tasks take over the memory and use it for their purposes.
0
 
BlaMAuthor Commented:
I finally found the problem and was able to fix it. Unfortunately it had nothing to do with the piece of code I posted here but memory was released accidently in another part of the code (Shame on my colleague who wrote the software *ggg* - Kept me busy for four days).

I'll credit the points to you nevertheless. Thanks for your help.
0

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 5
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now