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
Bronek Kozicki - 06 Apr 2006 11:18 GMT
> 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
[quoted text clipped - 8 lines]
> 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.
Willy Denoyette [MVP] - 06 Apr 2006 22:31 GMT
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.
| > 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
[quoted text clipped - 60 lines]
|
| B.
Bronek Kozicki - 07 Apr 2006 19:03 GMT
> 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
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_threa
d/thread/c41a3e407b6b25f0/
B.
Willy Denoyette [MVP] - 06 Apr 2006 22:40 GMT
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,
|
[quoted text clipped - 43 lines]
| Posted via http://www.codecomments.com
| ------------------------------------------------------------------------