[omniORB] compiling omniORB3 on NT -- Assertion failure
Ji-Yong D. Chung
virtualcyber@erols.com
Sun, 31 Oct 1999 21:54:02 -0500
This is a multi-part message in MIME format.
------=_NextPart_000_0022_01BF23EA.715AAAB0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thanks, Lars -- that cleared things up.
=20
I apologize for my mistakes, guys. Removing "inline" does make the =
assertion failures to vanish, but real problem was not (I think) that =
there are multiple definitions.
I linked Microsoft static run-time library against omniNames.exe, =
but I linked omniORB3 and omniDynamic3 against run-time dynamic =
libraries. It seems that this was causing problems. Apparently, all =
linkages must be performed against dynamic libraries or all must be =
linked against static libraries..
This likely was the cause of creating multiple heaps and the =
assertion failure. (I have not had opportunities to check things out =
fully, but this is the most likely thing -- of course, if not, then, I =
will have to retract my apology).
I suppose the MSVC's assertion failure did point out the problem -- =
only the problem turned out to be mine. Basically, I had to reset the =
linker options so that ALL modules linked against MSVCRTD.DLL.
Mike, take a look at Lars's email and the description of the =
assertion failure I had -- this probably will fix problems you had with =
2.8.0 also.
----- Original Message -----=20
From: Lars Immisch=20
To: Ji-Yong D. Chung=20
Cc: omniorb-list@uk.research.att.com=20
Sent: Sunday, October 31, 1999 8:57 AM
Subject: Re: [omniORB] compiling omniORB3 on NT -- Assertion failure
> I am not sure if, in Windows debugging mode, a dll does not treat =
the=20
> executing process' heap as if it were its own -- the terms "local heap =
of a
> DLL" maybe just semantics for MSVC debugger's accounting system for =
keeping
> track of memory allocated/deallocated from "the global heap" using the =
dll's
> exported functions.
>=20
> A MSVC++ expert (which I am not) would probably know
> whether this is true.
Not that I am an expert, but as far as I remember, a Win32 DLL has =
it's own heap if it's linked against the static C runtime libraries, but =
will share the heap with the process if both use the DLL C runtime =
libraries. If it is required that a process frees memory allocated by =
the omniORB DLLs, I would recommend you check that both the omniORB =
libraries and your process are linked against the dynamic libraries.
Hope this helps,
Lars Immisch
--
lars@ibp.de
------=_NextPart_000_0022_01BF23EA.715AAAB0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<?fontfamily><?param Helvetica><HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2> Thanks, Lars -- that cleared =
things=20
up.</FONT></DIV>
<DIV><FONT size=3D2> </FONT></DIV>
<DIV><FONT size=3D2> I apologize for my mistakes, =
guys. =20
Removing "inline" does make the assertion failures to vanish, but real=20
problem was not (I think) that there are multiple =
definitions.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2> I linked Microsoft static =
run-time=20
library against omniNames.exe, but I linked omniORB3 and omniDynamic3 =
against=20
run-time dynamic libraries. It seems that this was causing =
problems. =20
Apparently, all linkages must be performed against dynamic libraries or =
all must=20
be linked against static libraries..</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2> This likely was the cause of =
creating=20
multiple heaps and the assertion failure. (I have not had =
opportunities to=20
check things out fully, but this is the most likely thing -- of course, =
if not,=20
then, I will have to retract my apology).</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2> I suppose the MSVC's =
assertion failure=20
did point out the problem -- only the problem turned out to be =
mine. =20
Basically, I had to reset the linker options so that ALL modules linked =
against=20
MSVCRTD.DLL.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2> Mike, take a look at =
Lars's=20
email and the description of the assertion failure I had -- this =
probably will=20
fix problems you had with 2.8.0 also.</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
<DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV=20
style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
<A href=3D"mailto:lars@ibp.de" title=3Dlars@ibp.de>Lars Immisch</A> =
</DIV>
<DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
href=3D"mailto:virtualcyber@erols.com" =
title=3Dvirtualcyber@erols.com>Ji-Yong D.=20
Chung</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A=20
href=3D"mailto:omniorb-list@uk.research.att.com"=20
=
title=3Domniorb-list@uk.research.att.com>omniorb-list@uk.research.att.com=
</A>=20
</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Sunday, October 31, 1999 =
8:57=20
AM</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: [omniORB] =
compiling omniORB3=20
on NT -- Assertion failure</DIV>
<DIV><BR></DIV>> I am not sure if, in Windows debugging mode, a dll =
does=20
not treat the <PRE>> executing process' heap as if it were its own =
-- the terms "local heap of a
> DLL" maybe just semantics for MSVC debugger's accounting system for =
keeping
> track of memory allocated/deallocated from "the global heap" using =
the dll's
> exported functions.
>=20
> A MSVC++ expert (which I am not) would probably know
> whether this is true.
</PRE><BR>Not that I am an expert, but as far as I remember, a Win32 DLL =
has=20
it's own heap if it's linked against the static C runtime libraries, =
but will=20
share the heap with the process if both use the DLL C runtime =
libraries. If it=20
is required that a process frees memory allocated by the omniORB DLLs, =
I would=20
recommend you check that both the omniORB libraries and your process =
are=20
linked against the dynamic libraries.<BR><BR>Hope this =
helps,<BR><BR>Lars=20
=
Immisch<BR>--<BR>lars@ibp.de<BR></BLOCKQUOTE><?/fontfamily></BODY></HTML>=
------=_NextPart_000_0022_01BF23EA.715AAAB0--