_bstr_t leads to a crash

**Bronek Kozicki** · Apr 6 '06, 11:06 AM

Re: _bstr_t leads to a crash

ashish_chap wrote:[color=blue]
> I am using _bstr_t class in a function. This is used in an application
> that is used in an multi-threaded environment. The function is
> implemented as follows:
> Also, it crashes sometimes when the function returns and destructor for
> _bstr_t is called.
>
> Please, help me find out the answers to the following questions.
> 1) Is there any limitation for the overloaded '=' operation in _bstr_t,
> due to which somestimes the sqlCmd is not assigned to cmd.
>
> 2)Before calling the destructor for _bstr_t is there any operation that
> should be used to avoid the crash?[/color]

as _bstr_t is simply encapsulation for COM support functions (SysAllocString ,
SysFreeString etc. ) You should not use these function when COM susbsystem is
(not yet or already) unavailable. What you do is:

1. initialize _bstr_t before COM is available (_bstr_t may delay call to
SysAllocString till you actually put something in it, but you are still in danger)

2. I also guess that you call CoUninitialize before _bstr_t destructor is
called. This means that when SysFreeString is called, there is no COM
sybsystem to handle your call.

What you should do is to initialize COM before you start any COM-related
activity and un-initialize when you are 100% done. Like here:

#include <cstdio>
#include <stdexcept>

#include <comdef.h>
#include <comutil.h>

int main()
{
int result = 13;
if (FAILED(CoIniti alize(NULL)))
{
puts("Failed to initialize COM");
return result;
}

try
{
_bstr_t a = "blablabla" ;
// .... call your functions that use COM
result = 0;
}
catch(std::exce ption& e)
{
puts(e.what());
result = 1;
}
catch(_com_erro r e)
{
puts(static_cas t<const char*>(e.Descri ption()));
result = 2;
}

CoUninitialize( );
return result;
}

B.

**Willy Denoyette [MVP]** · Apr 6 '06, 09:45 PM

Re: _bstr_t leads to a crash

No, this is not true. The _bstr_t wrapper does not depend on the COM library
(initialized by a CoInitialize call), you can use this class without calling
into COM.

Willy.

"Bronek Kozicki" <brok@rubikon.p l> wrote in message
news:eeufwNWWGH A.5012@TK2MSFTN GP05.phx.gbl...
| ashish_chap wrote:
| > I am using _bstr_t class in a function. This is used in an application
| > that is used in an multi-threaded environment. The function is
| > implemented as follows:
| > Also, it crashes sometimes when the function returns and destructor for
| > _bstr_t is called.
| >
| > Please, help me find out the answers to the following questions.
| > 1) Is there any limitation for the overloaded '=' operation in _bstr_t,
| > due to which somestimes the sqlCmd is not assigned to cmd.
| >
| > 2)Before calling the destructor for _bstr_t is there any operation that
| > should be used to avoid the crash?
|
|
| as _bstr_t is simply encapsulation for COM support functions
(SysAllocString ,
| SysFreeString etc. ) You should not use these function when COM susbsystem
is
| (not yet or already) unavailable. What you do is:
|
| 1. initialize _bstr_t before COM is available (_bstr_t may delay call to
| SysAllocString till you actually put something in it, but you are still in
danger)
|
| 2. I also guess that you call CoUninitialize before _bstr_t destructor is
| called. This means that when SysFreeString is called, there is no COM
| sybsystem to handle your call.
|
| What you should do is to initialize COM before you start any COM-related
| activity and un-initialize when you are 100% done. Like here:
|
| #include <cstdio>
| #include <stdexcept>
|
| #include <comdef.h>
| #include <comutil.h>
|
| int main()
| {
| int result = 13;
| if (FAILED(CoIniti alize(NULL)))
| {
| puts("Failed to initialize COM");
| return result;
| }
|
| try
| {
| _bstr_t a = "blablabla" ;
| // .... call your functions that use COM
| result = 0;
| }
| catch(std::exce ption& e)
| {
| puts(e.what());
| result = 1;
| }
| catch(_com_erro r e)
| {
| puts(static_cas t<const char*>(e.Descri ption()));
| result = 2;
| }
|
| CoUninitialize( );
| return result;
| }
|
|
| B.

**Willy Denoyette [MVP]** · Apr 6 '06, 09:55 PM

Re: _bstr_t leads to a crash

Is this function a thread procedure? Then you need to CoUnitialize before
returning.
If it's not a thread proc, you should not CoInitialize here.

Willy.

"ashish_cha p" <ashish_chap.25 u4hs@mail.codec omments.com> wrote in message
news:ashish_cha p.25u4hs@mail.c odecomments.com ...
|
| Hi,
|
| I am using _bstr_t class in a function. This is used in an application
| that is used in an multi-threaded environment. The function is
| implemented as follows:
|
| int Function(wchar_ t *sqlCmd)
| {
| _bstr_t cmd ;
|
| cmd = sqlCmd ;
| CoInitialize(NU LL);
| .
| .
| .
| return 0;
| }
|
|
| The above function uses ADO functions to execute SQL command. Here, in
| statement
|
| cmd = sqlCmd
|
| while executing sqlCmd "Sometimes" an exception is thrown this happens
| because though sqlCmd contains the sqlCmd to be executed. It is not
| assigned to cmd which is passed to Execute function of ADODB.
|
| Also, it crashes sometimes when the function returns and destructor for
| _bstr_t is called.
|
| Please, help me find out the answers to the following questions.
| 1) Is there any limitation for the overloaded '=' operation in _bstr_t,
| due to which somestimes the sqlCmd is not assigned to cmd.
|
| 2)Before calling the destructor for _bstr_t is there any operation that
| should be used to avoid the crash?
|
| Thanks for you time.
|
| Regards,
| Ashish Choudhary
|
|
|
| --
| ashish_chap
| ------------------------------------------------------------------------
| Posted via http://www.codecomments.com
| ------------------------------------------------------------------------
|

**Bronek Kozicki** · Apr 7 '06, 06:25 PM

Re: _bstr_t leads to a crash

Willy Denoyette [MVP] wrote:[color=blue]
> No, this is not true. The _bstr_t wrapper does not depend on the COM library
> (initialized by a CoInitialize call), you can use this class without calling[/color]

indeed, you are right, thanks for rectifying my mistake. However, if there is
any use of other COM wrappers (#import etc), these will release COM objects at
the point of their destruction (end of scope). If that comes after
CoUninitialize, memory access violation will happen. The other thing coming to
my mind is misuse of _bstr_t , I gave explanation and code samples in this thread:

http://groups.google.com/group/microsoft.public.dotnet.languages.vc/browse_thread/thread/c41a3e407b6b25f0/

B.

_bstr_t leads to a crash

_bstr_t leads to a crash

Comment

Comment

Comment

Comment