[omniORB] string_dup() behavior
baileyk@schneider.com
baileyk@schneider.com
Fri Jul 12 20:57:00 2002
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