[omniORB] string_dup() behavior
Lionel Gilet
lgilet@san-jose.tt.slb.com
Fri Jul 12 23:08:00 2002
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