Re: String to VT_BSTR conversion problem

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

"Karl B" <nospam@home> wrote in message
news:05k302pckg1s9lcja1sviloji51ors2i75@xxxxxxx
"Igor Tandetnik" <itandetnik@xxxxxxxx> wrote:

Karl B <nospam@home> wrote:
I'm new to COM and trying to convert an std::string into a
tagVARIANT of type VT_BSTR. I'm using an intermediate CComVariant
to achieve this, however the code appears to be causing a memory
leak. The following code demonstrates this in an exagerated fashion:

int iterations = 10000;
while(--iterations)
{
temp = str.c_str();
temp.ChangeType(VT_BSTR);

VariantCopy(&aDest, &temp);
VariantClear(&temp);
Sleep(10);
}
}

I don't see memory leaks inside the loop. The only leak is when you
fail to free aDest at the end of the loop - it still holds the last
string placed into it. What makes you think there is a major memory
leak here?

Thanks for the response. When I bring up task manager, memory usaage
reported for the above rises by a few kilobytes a second. This only
happens when compiling in Release mode. I have the final free in the
real code - missed a bit on the example.

Interesting. I see the memory grow when compiled with VC6, but not with
VC7.1. Let's dig deeper...

Got it. CComVariant::operator=(LPCSTR) uses A2COLE macro internally,
which allocates a temporary buffer on the stack using _alloca. Memory
allocated with _alloca only gets freed after the enclosing function
returns. It is a bad idea to call it in a loop - the consumed stack
space just keeps growing until stack overflow occurs.

Now, in Release build, VC6 compiler inlined CComVariant::operator= which
resulted in _alloca being called directly within your loop, hence the
memory growth.

As a workaround, move ANSI to Unicode conversion outside the loop:

std::string str("Hello Hello Hello Hello Hello Hello Hello Hello Hello
Hello ");
CComBSTR bstr = str.c_str();

and replace str.c_str() with bstr in the rest of your code. That, or
upgrade to a newer compiler where the problem is fixed.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925


.

Relevant Pages

  • Re: Possible memory leak using $sth->{NAME} ?
    ... > routine seems to leak 1 SV per execution. ... > to be a fairly insignificant amount of memory. ... > of memory per trip through the loop. ... > version of the script where the loop executes once, ...
    (perl.dbi.users)
  • Re: MDAC memory leak
    ... Most libraries place the decision of when to free ... There's a capability of breaking on a particular memory allocation, ... leak 500 objects, on the second test I leak 3, because I fixed the bug). ... "App shows memory leak on some machines." ...
    (microsoft.public.vc.mfc)
  • Re: MDAC memory leak
    ... Also when we used some of the memory leak tools suggested on microsoft site ... A mutex is a considerably less efficient synchronization ... "App shows memory leak on some machines." ...
    (microsoft.public.vc.mfc)
  • Re: Possible memory leak using $sth->{NAME} ?
    ... I'm actually not too concerned about that particular leak -- it seems ... to be a fairly insignificant amount of memory. ... of memory per trip through the loop. ... use DBI; ...
    (perl.dbi.users)
  • Re: Help! define_method leaking procs...
    ... >>> VmSize value. ... there is no evidence yet that ruby is not ... I am not saying there is no memory leak ...
    (comp.lang.ruby)