[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>&nbsp;&nbsp;&nbsp; Thanks, Lars -- that cleared =
things=20
up.</FONT></DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; </FONT></DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; I apologize for my mistakes, =
guys.&nbsp;=20
Removing "inline" does make the assertion failures to vanish, but real=20
problem&nbsp;was not (I think) that there are multiple =
definitions.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; I&nbsp;linked Microsoft static =
run-time=20
library against omniNames.exe, but I linked omniORB3 and omniDynamic3 =
against=20
run-time dynamic libraries.&nbsp; It seems that this was causing =
problems.&nbsp;=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>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; This likely was the cause of =
creating=20
multiple heaps and the assertion failure.&nbsp; (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>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;I suppose the MSVC's =
assertion failure=20
did point out the problem -- only the problem turned out to be =
mine.&nbsp;=20
Basically, I had to reset the linker options so that ALL modules linked =
against=20
MSVCRTD.DLL.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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>&gt; I am not sure if, in Windows debugging mode, a dll =
does=20
  not treat the <PRE>&gt; executing process' heap as if it were its own =
-- the terms "local heap of a
&gt; DLL" maybe just semantics for MSVC debugger's accounting system for =
keeping
&gt; track of memory allocated/deallocated from "the global heap" using =
the dll's
&gt; exported functions.
&gt;=20
&gt; A MSVC++ expert (which I am not) would probably know
&gt; 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--