<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>
<META content="MSHTML 6.00.6000.16809" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2></FONT> </DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT
face=Tahoma size=2>-----Original Message-----<BR><B>From:</B>
omniorb-list-bounces@omniorb-support.com
[mailto:omniorb-list-bounces@omniorb-support.com] <B>On Behalf Of </B>Andrew
Buza<BR><B>Sent:</B> Friday, June 19, 2009 5:39 PM<BR><B>To:</B>
omniORB-list@omniorb-support.com<BR><B>Subject:</B> [omniORB] question
regarding ORB initialization in DLLs and somegeneral
problems<BR><BR></FONT></DIV>I have multiple DLLs (used as extensions to a 3rd
party application) that use omniORB and I'm having quite a bit of trouble
getting everything working. I've read section 4.5.1 (ORB initialization) of
the CORBA architecture spec, but I'm not sure what the correct way to
initialize omniORB is when it's used by multiple DLLs loaded by the same
process.
<DIV><BR></DIV>
<DIV>For instance, should each library call ORB_init or must it be done only
once (and the resulting ORB_ptr exported to other dlls in some way)?<SPAN
class=126461616-22062009><FONT face=Arial color=#0000ff
size=2> </FONT></SPAN></DIV>
<DIV><SPAN class=126461616-22062009></SPAN> </DIV>
<DIV><SPAN class=126461616-22062009><FONT face=Arial color=#0000ff
size=2>The ORB is a singleton - it's created by the first call
to ORB_init(), and each subsequent call to ORB_init() should return a
reference to the same object - you shouldn't need to export the reference if
everything that needs the ORB is calling ORB_init(). The one
thing that you might need to do is to make sure that you
get the ORB initialized with every argument/option that you
need before some other piece of code gets to it.</FONT> </SPAN></DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT><BR></DIV>
<DIV>Right now my project is a mess. When linking to omniorb statically,
ORB_init will cause an access violation in logiostream.cc:516 (a call to
fputs), and when linked dynamically it will cause the same when calling
delete[] in any CORBA sequence. If I move back to omniORB-4.1.0 I no
longer have problems with initalization and destruction, but calling methods
of *_vars passed across module boundaries will cause access violations in
omni_mutex::lock. <SPAN class=126461616-22062009><FONT face=Arial
color=#0000ff size=2> </FONT></SPAN></DIV>
<DIV><SPAN class=126461616-22062009></SPAN> </DIV>
<DIV><SPAN class=126461616-22062009><FONT face=Arial color=#0000ff
size=2>Well, a CORBA sequence isn't an array - it's a just a class that
overrides operator[] - so delete should be used, not
delete[].</FONT> <FONT face=Arial color=#0000ff size=2> Or you could
just stick with the _var and _ptr types.</FONT></SPAN></DIV>
<DIV><BR></DIV>
<DIV>I've made sure that everything is linking with the correct runtime
library as mentioned in the wiki. I feel like I must be doing something
fundamentally wrong, but I'm not sure exactly what that might be -- any
suggestions would be welcome.<SPAN class=126461616-22062009><FONT face=Arial
color=#0000ff size=2> </FONT></SPAN></DIV>
<DIV><SPAN class=126461616-22062009></SPAN> </DIV>
<DIV><SPAN class=126461616-22062009><FONT face=Arial color=#0000ff
size=2>Check what the other DLLs are linked against. (dumpbin
/imports [dll name]). I had a problem with libraries
using different c runtime libraries a few years ago. I don't have
the code anymore, but as I remember, it involved some creative rearranging
of includes and linking. However, I think that it produced
link errors, not runtime problems, so if you're able to build,
you're probably ok.</FONT> </SPAN></DIV>
<DIV><BR></DIV>
<DIV>I'm using omniORB-4.1.3 (compiled with /Zc:wchar_t) and msvc 7.1.6030.
The same projects are also built with msvc 8 and work fine. The application
that loads my DLLs (Adobe InDesign) appears to be involved in (de)allocation
in some way since one of its dlls appears in the call stack between the call
to operator delete[] in my code and the implementation in ntdll.dll. Might
this be the source of some of my problems?<FONT face=Arial><FONT
color=#0000ff><FONT size=2><SPAN
class=126461616-22062009> </SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=126461616-22062009></SPAN></FONT></FONT></FONT> </DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=126461616-22062009>That sounds like someone snuck an
operator[] delete or #defined free somewhere. Check the header(s) for the
offending dll.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=126461616-22062009></SPAN></FONT></FONT></FONT> </DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=126461616-22062009></SPAN></FONT></FONT></FONT>Thanks for any help
anyone can provide, even if it's just a pointer to some information or a
better place for these sorts of questions.</DIV></BLOCKQUOTE>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV><SPAN class=126461616-22062009><FONT face=Arial color=#0000ff size=2>If
you have other libraries that are using omniorb, I would try to confirm that
everything is building against the same omniorb that you are using. Some
sort of binary incompatability would explain the random problems that you
described.</FONT></SPAN></DIV></BLOCKQUOTE></BODY></HTML>