[omniORB] string_dup() behavior
Norrie Quinn
norrie.quinn@tumbleweed.com
Fri Jul 12 23:32:01 2002
> I will try to remove the inline as soon as I get a chance.
Don't go down that path.
> Can I resolve the problem another way by compiling and
> linking my executable with the same runtime
> used by the omni DLL? Wouldn't that be as simple as building
> them with the same compiler options?
Yes. Use /MD in your project as stated earlier. In Visual Studio 6 it is
Project Settings/C++/Code Generation/Use runtime library: Multithreaded DLL
Norrie
> -----Original Message-----
> From: Lionel Gilet [mailto:lgilet@san-jose.tt.slb.com]
> Sent: Friday, July 12, 2002 3:09 PM
> To: omniorb-list@realvnc.com
> Subject: Re: [omniORB] string_dup() behavior
>
>
> Your explanation makes a lot of sense and appears consistent
> with all the tests I have done.
> I have checked the source code and you are correct that
> CORBA::string_dup() is not inline while all
> the String_var methods are inline as well as the string
> methods in the omni name space on which
> they depend.
> I will try to remove the inline as soon as I get a chance.
> Can I resolve the problem another way by compiling and
> linking my executable with the same runtime
> used by the omni DLL? Wouldn't that be as simple as building
> them with the same compiler options?
>
> Has anybody run into this problem before? I would be amazed
> to be the only one using omniORB3 on
> Windows.
>
> Thank you
>
> Lionel Gilet
>
> Schlumberger / NPtest
>
>
> baileyk@schneider.com wrote:
>
> > I'm no expert on Windows, but I'll give it a shot.
> >
> > Each DLL version of the runtime library ( there's single
> threaded debug,
> > single threaded release, multithreaded debug and
> multithreaded release at
> > least) can not delete a memory allocation made by any other
> DLL version of
> > the runtime library. Each DLL and EXE you link together
> has a dependency
> > on some runtime version. As long as each DLL deletes the
> things that it
> > news all is OK even if you mix together runtimes.
> >
> > I'm looking at the source for omniORB4. I can see that
> CORBA::string_dup()
> > is not inlined. It calls _CORBA_String_helper::dup() which
> is inlined. A
> > call to CORBA::string_dup() then could not be inlined into
> your code. A
> > call to CORBA::string_dup() then must return memory allocated by the
> > runtime linked to the omniORB DLL.
> >
> > I can't find a String_var::string_dup(), but lets assume
> there was one in
> > omniORB3. All of the methods I see in String_var are
> inlined and call
> > directly to the _CORBA_String_helper functions, which are
> also inlined. So
> > the destructor of String_var, which does the delete, can be
> inlined and so
> > the delete is called directly from your code, not the
> omniORB DLL. If your
> > code does not link to the same runtime DLL as the omniORB
> DLL and you use
> > the non-inlined CORBA::string_dup it will fail. If
> String_var::string_dup
> > () is also inlined then you are OK. I'll look in CVS at
> the omniORB3
> > source to try to verify my theory.
> >
> > I think if you were to make all of the static functions in
> > _CORBA_String_helper non-inline, the problem would go away.
> I'm somewhat
> > disturbed that they are inline. I believe the need for these CORBA
> > specific memory allocators is precisely to work around this
> problem. By
> > making them inline it defeats the purpose. All ORB related memory
> > allocations should be done from within the ORB DLLs in
> order for the very
> > existence of the CORBA::string_* functions to make sense.
> >
> > I'm just glad I don't develop for Windows anymore.
> >
> > Kendall
> >
> > p.s. I glanced in CVS and found that _CORBA_String_helper
> does not exist in
> > the stringtypes.h header file. Instead there are functions
> in the omni
> > namespace for string allocation. If these are inlined,
> then the argument
> > above still holds.
> >
> >
> > Lionel Gilet
> > <lgilet@san-jose.tt. To:
> omniorb-list@realvnc.com
> > slb.com> cc:
> > Sent by: Fax to:
> > omniorb-list-admin@r Subject:
> Re: [omniORB] string_dup() behavior
> > ealvnc.com
> >
> >
> > 07/12/2002 12:22 PM
> >
> >
> >
> > Let me provide a bit more info.
> > I am using Visual Studio.NET and Windows 2000.
> >
> > The compiler options are:
> > /nologo /Od /Z7 /D__WIN32__ /D__x86__ /D__NT__ /D__OSVERSION__=4
> > The executable is linked with:
> > omniORB304_rt.lib
> > omnithread2_rt.lib
> > omniDynamic304_rt.lib
> >
> > The code is pretty much reduced to:
> > {
> > CORBA::String_var theString = CORBA::string_dup((const
> char*) "name");
> > }
> >
> > When I reach the end of scope I get:
> > HEAP: Invalid Address specified to RtlFreeHeap ( 510000, 417d18 )
> >
> > Again I do not get the problem if I use
> CORBA::String_var::string_dup() or
> > if I link with the static
> > libraries.
> >
> > I also tried:
> > {
> > char* newName = new char [10];
> > strcpy(newName, "name");
> > CORBA::String_var theString = CORBA::string_dup(newName);
> > }
> >
> > and I get the same result.
> >
> > CORBA::string_dup() does duplicate the string so I really
> do not understand
> > why the string member can
> > not be deleted and why the behavior is fine with
> > CORBA::String_var::string_dup();
> >
> > Thank you for sharing your ideas,
> >
> > Lionel Gilet
> >
> > Schlumberger / NPtest
> >
> > baileyk@schneider.com wrote:
> >
> > > My guess is the problem is caused by a mix of different
> runtime libraries
> > > too. I don't run omniORB on Windows but I've done enough
> Windows DLL
> > > programming to know how easy it is to fall into that trap.
> > >
> > > I don't agree that one needs to cast all string literals.
> If you use
> > > CORBA::string_dup, you don't need to also cast the
> argument. If you are
> > > constructing a String_var directly, then yes.
> > >
> > > CORBA::String_var theString("name"); // not a good idea
> on all platforms
> > >
> > > CORBA::String_var theString((char const*)"name"); // more reliable
> > >
> > > But I always just use CORBA::string_dup() to make it
> clear that a copy is
> > > being made.
> > >
> > > Kendall
> > >
> > >
> > > "Visscher, Bruce"
> > > <VISSCHB@rjrt.com> To:
> "Lionel Gilet"
> > <lgilet@san-jose.tt.slb.com>,
> > > Sent by: "OmniOrb List"
> > <omniorb-list@realvnc.com>
> > > omniorb-list-admin@r cc:
> > > ealvnc.com Fax to:
> > > Subject:
> RE: [omniORB]
> > string_dup() behavior
> > >
> > > 07/11/2002 08:08 PM
> > >
> > >
> > >
> > > > {
> > > > CORBA::String_var the String = CORBA::string_dup("name");
> > > > }
> > >
> > > I don't really see why this should be a problem (except
> for the obvious
> > > typo in the variable name).
> > >
> > > Are you sure you used consistent compiler options? If
> you link against
> > the
> > > omniORB DLLs you must configure your project to compile
> > > and link against the multi-threaded DLL version of the
> MSC run time.
> > >
> > > In any case, you should always cast literal strings to
> "pointer to const
> > > char" to be on the safe side. The C++ standard mandates
> > > that string literals are of this type already so the cast
> wouldn't be
> > > needed with a standards conforming compiler.
> > >
> > > The CORBA C++ mapping made some unfortunate choices
> regarding pointers to
> > > non-const char.
> > >
> > > HTH,
> > >
> > > Bruce
> > > (See attached file: InterScan_Disclaimer.txt)
> > >
> > >
> >
> --------------------------------------------------------------
> ----------
> > > Name: InterScan_Disclaimer.txt
> > > InterScan_Disclaimer.txt Type: Plain Text (text/plain)
> > > Encoding: BASE64
> >
> > _______________________________________________
> > omniORB-list mailing list
> > omniORB-list@realvnc.com
> > http://www.realvnc.com/mailman/listinfo/omniorb-list
> >
> > _______________________________________________
> > omniORB-list mailing list
> > omniORB-list@realvnc.com
> > http://www.realvnc.com/mailman/listinfo/omniorb-list
>
>
> _______________________________________________
> omniORB-list mailing list
> omniORB-list@realvnc.com
> http://www.realvnc.com/mailman/listinfo/omniorb-list
>