[omniORB] string_dup() behavior
Lionel Gilet
lgilet@san-jose.tt.slb.com
Sat Jul 13 00:38:01 2002
The problem is that I have already tried /MD and pretty much any compiler
option that looked relevent and nothing works. However, I am fairly new to VC
so I am going to assume that I am doing something wrong here and I am just
going to have to dig a bit more on the environment to figure out what it is.
Thank you
Lionel Gilet
Schlumberger / NPtest
Norrie Quinn wrote:
> > 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
> >