Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / Managed C++ / April 2006

Tip: Looking for answers? Try searching our database.

_bstr_t  leads to a crash

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
ashish_chap - 06 Apr 2006 07:23 GMT
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
| ------------------------------------------------------------------------

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.