[omniORB] compiling omniORB3 on NT -- Assertion failure

Ramesh V. Shaastri RShaast@sivam.gar.esys.com
Sun, 31 Oct 1999 08:44:54 -0600


This is a multi-part message in MIME format.
--------------E14602DD74FC0B77C1F1D9A9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Ji-Yong D. Chung" wrote:

>     I am not sure if, in Windows debugging mode, a dll does not treat the
> 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.
>

Actually I think it is the other way around. A process treats dynamic memory
allocated from the heap within a DLL as its own.

In general, dynamic memory allocated from the heap in a function within a DLL
will belong to the process that attaches to the DLL and calls the function.
Memory allocated from the heap in a function in the attaching process belongs
to the process. The exception to the first statement is if the DLL implements a

shared memory allocation model (e.g. using file mapping). In which case,
several processes can share the same [global] chunk of memory.

But I am not sure why the debug mode will treat memory allocations in a DLL any

differently than in non-debug mode.

Then again, I am not a MSVC++/MSWindows expert.

>
>     A MSVC++ expert (which I am not) would probably know
> whether this is true.
>
>     One thing is for sure -- if allocation of memory is done by a function
> exported from a dll, the deallocation also must be done by an exported
> function of the dll. Of course, there is no restriction as to what modules
> can invoke the exported functions.
>
>     This is not such a bad debug requirement -- it really helps one in
> debugging and tracking memory errors by
>
>     Remember, in non-debug environment, there would be no assertion failures
> regarding this "local" heap.

--------------E14602DD74FC0B77C1F1D9A9
Content-Type: text/x-vcard; charset=us-ascii;
 name="RShaast.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ramesh V. Shaastri
Content-Disposition: attachment;
 filename="RShaast.vcf"

begin:vcard 
n:Shaastri;Ramesh
tel;fax:972.205.4630
tel;work:972.205.6733
x-mozilla-html:TRUE
url:www.Raytheon.com
org:<FONT COLOR="#FF0000"><B>Raytheon</B></FONT><!--<a href="http://www.raytheon.com/rsc">--><!--<img src="http://www.raytheon.com/rsc/images/ray2logo.gif" alt="Raytheon Systems Company" width=115 height=28>--><!--</a>-->;<b>C3I <i>SIVAM</i></b>
version:2.1
email;internet:RShaast@SIVAM.Gar.ESys.Com
title:Sr. S/W Engineer II
adr;quoted-printable:;;501 S. Jupiter Road=0D=0A;Garland;TX;75042-7108;
note;quoted-printable:<font size=3D-1><i>=0D=0A"...do it badly, do it quickly,=0D=0A make it better,=0D=0A and then say you planned it."=0D=0A - Tom Peters '90=0D=0A</i></font>=0D=0A
x-mozilla-cpt:guianan.gar.esys.com;-28384
fn:Ramesh V. Shaastri
end:vcard

--------------E14602DD74FC0B77C1F1D9A9--