[omniORB] ActiveX

[Sai-Lai Lo]

Helge,

We do use tools like purify to ensure there is no memory leak.  In fact,
for the past 2 years, I don't recall a single report on memory leak that
causes the applications to grow in time.

I admit there are one off allocations, singleton objects that are not
deallocated when the program exit. However, these are one-off allocations
that do not grow in time. Together they form the skeleton from which all
the object implementations and object references hang off.

Remember CORBA object implementations are allocated by the application and
registered with the ORB. It is close to impossible to deallocate them
unilaterally inside the ORB. The same applies to object references returned
to the application. 

Can we deallocate everything else then? Probably yes but in doing so we
probably have to compromise the consistency check that is in place to
ensure that applications do not see things deleted under their feet. These
checks are what give omniORB the robustness and for us to tell where the
problem lies when a user reports a crash in the runtime. It is difficult
enough to work out, just from the ORB's warning or trace message or
assertions, if it is a real bug in the ORB or if it is just a bug in the
application.  It will be even harder if we are not sure that the ORB is
always internally consistent, even during shutdown.


Regards,

Sai-Lai

-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND