_bstr_t leads to a crash

  • Thread starter Thread starter ashish_chap
  • Start date Start date
A

ashish_chap

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(NULL);
..
..
..
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 said:
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?
Click to expand...


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(CoInitialize(NULL)))
{
puts("Failed to initialize COM");
return result;
}

try
{
_bstr_t a = "blablabla";
// .... call your functions that use COM
result = 0;
}
catch(std::exception& e)
{
puts(e.what());
result = 1;
}
catch(_com_error e)
{
puts(static_cast<const char*>(e.Description()));
result = 2;
}

CoUninitialize();
return result;
}


B.
 
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.

| 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(CoInitialize(NULL)))
| {
| puts("Failed to initialize COM");
| return result;
| }
|
| try
| {
| _bstr_t a = "blablabla";
| // .... call your functions that use COM
| result = 0;
| }
| catch(std::exception& e)
| {
| puts(e.what());
| result = 1;
| }
| catch(_com_error e)
| {
| puts(static_cast<const char*>(e.Description()));
| result = 2;
| }
|
| CoUninitialize();
| return result;
| }
|
|
| B.
 
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.

|
| 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(NULL);
| .
| .
| .
| 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
| ------------------------------------------------------------------------
|
 
Willy said:
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
Click to expand...

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/micr...ges.vc/browse_thread/thread/c41a3e407b6b25f0/


B.
 
Back
Top