Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

[tao-users] Memory leak(s) in 1.1.2 -- Sequences in Anys

15 views

Skip to first unread message

Tom Ziomek

unread,

May 18, 2000, 3:00:00 AM5/18/00

TAO VERSION: 1.1.2
ACE VERSION: 5.1.2

HOST MACHINE and OPERATING SYSTEM: Pentium II, WinNT 4.0 SP3
TARGET MACHINE and OPERATING SYSTEM, if different from HOST: same
COMPILER NAME AND VERSION (AND PATCHLEVEL): DevStudio 6.0 SP3

Also, my config.h contains:
#define ACE_HAS_STANDARD_CPP_LIBRARY 1
#define ACE_HAS_MFC 1
#include "ace/config-win32.h"

AREA/CLASS/EXAMPLE AFFECTED: Passing an Any containing a Union containing
a sequence.

DOES THE PROBLEM AFFECT:
COMPILATION? No
LINKING? No
EXECUTION? Yes
OTHER (please specify)?

SYNOPSIS: Passing an Any containing a Union containing a sequence through
a CORBA call leaks ~1K of memory. The problem may go deeper; I have a
struct inside the sequence.

DESCRIPTION: See below.

REPEAT BY: See below.

SAMPLE FIX/WORKAROUND: I am considering either replacing the sequences in
our IDL with fixed length arrays or using sequence<octet> in plact of the
Any (even if either of those doesn't leak, which I haven't tried yet, both
workarounds are undesirable for our product).

===========================================================================
The following should allow you to reproduce the problem. I am appending a
simple IDL file, one client-side source file, three server-side source
files, an ASCII version of the processes' memory usage as seen with WinNT's
Performance Monitor, and a subset of our NuMega BoundsChecker report for
the server process.

The IDL file is compiled w/ no options other than '-I' for the TAO and
orbsvcs directories. No svc.conf file is used and no command line args are
passed to the ORB.

You'll see my IDL union can contain a short, a simple struct, or the se-
quence. If the active member is the short or the struct, no leak occurs.

The leak also occurs even if the server never performs an extraction from
the Any.

===========================================================================

// IDL
module Test
{
struct Tstruct
{
short ShortSElem;
long LongSElem;
};

typedef sequence<Tstruct> TstructSeq;

union Tunion switch (short)
{
case 1: short ShortUElem;
case 2: Tstruct StructUElem;
case 3: TstructSeq SeqUElem;
};

interface Server
{
void PushAny(in Any data);
void Shutdown();
};
};

===========================================================================

[The only client source file. This should compile & link into an executa-
ble by itself.]

// Client_main.cpp

#include "ServerC.h"

const int NUM_MRS = 3;
const int USEC_DELAY = 1000;

/*-------------------------------------------------------------*/

int main (int argc, char *argv[])
{
Test::Server_var vServer;
CORBA::ORB_var vOrb;
CORBA::Object_var vObject;
CORBA::String_var vString;
ifstream fileIn;

// STARTUP
vOrb = CORBA::ORB_init(argc, argv);
// Get NT service IOR from file 'ServerIOR'
fileIn.open("ServerIOR");
char buffer[1000];
fileIn >> buffer;
vString = CORBA::string_dup(buffer);
fileIn.close();
vObject= vOrb->string_to_object(vString.in());
vServer = Test::Server::_narrow(vObject.in());

// RUN
CORBA::Short i;
Test::Tstruct testStruct;
Test::TstructSeq testSeq;
Test::Tunion testUnion;
CORBA::Any any;
int numIter;

cout << "Size of Test::Tstruct is " << sizeof(testStruct) << endl;
cout << "Size of Test::TstructSeq is " << sizeof(testSeq) << endl;
cout << "Size of Test::Tunion is " << sizeof(testUnion) <<endl;
cout << endl;

cout << "How many calls should be made? ";
cin >> numIter;
cout << "Sending " << numIter << " sequences in Anys..." << endl;

for ( i = 0; i < numIter; i++ )
{
// No server-side leak if the union's 'short' or 'struct' elements
// were used instead.
testSeq.length(1);
testSeq[0].ShortSElem = i;
testSeq[0].LongSElem = i + 1024 * 64;
testUnion.SeqUElem(testSeq);
// Insertion is by reference, which should make a deep copy into
// newly-allocated memory. Memory already owned by the Any should
// first be freed. If we were inserting by pointer than the Any
// would take ownership of the pointed-to memory.
any <<= testUnion;
vServer->PushAny(any);
ACE_OS::sleep(ACE_Time_Value(0, USEC_DELAY));
};

// All done, go bye-bye
ACE_OS::sleep(2);
vServer->Shutdown();
return 0;
} /* main() */

/*-- End Client_main.cpp --------------------------------------*/

===========================================================================

[The three server-side files -- a .h and .cpp for the implementation, and
a main that creates/activates it and runs the CORBA thread.]

// Server_impl.h
/* CORBA object that receives the data from the client. */

#include "ServerS.h"

class Server_impl : public POA_Test::Server,
public virtual PortableServer::RefCountServantBase
{
public:
Server_impl(int argc, char ** argv) :
m_argc(argc),
m_argv(argv),
m_count(0)
{};
~Server_impl() {};

// IDL interfaces
void PushAny(const CORBA::Any & data);
void Shutdown(void);

private:
int m_argc;
char ** m_argv;
int m_count;
};

/*-- End Server_impl.h ----------------------------------------*/

===========================================================================

// Server_impl.cpp

#include "Server_impl.h"

/*-------------------------------------------------------------*/

void Server_impl::PushAny(const CORBA::Any& data)
{
Test::Tunion * pUnion;

m_count++;

// Leaks even if the extraction below were not done.
if ( data >>= pUnion ) // The Any still owns the memory ref'ed by pUnion
{
cout << "PushAny(): received #" << m_count << " as a Tunion" << endl;
}
else
{
cout << "#" << m_count << ": PushAny() couldn't extract anything" << endl;
}

} /* PushAny() */

/*-------------------------------------------------------------*/

void Server_impl::Shutdown(void)
{
CORBA::ORB_init(m_argc, m_argv)->shutdown(FALSE);
} /* Shutdown() */

/*-------------------------------------------------------------*/
/*-- End Server_impl.cpp --------------------------------------*/

===========================================================================

// Server_main.cpp

#include "Server_impl.h"

/*-------------------------------------------------------------*/

int main (int argc, char *argv[])
{
Server_impl servant(argc, argv);
Test::Server_var vServer;
CORBA::ORB_var vOrb;
CORBA::Object_var vPoa;
PortableServer::POA_var vRootPoa;
PortableServer::POAManager_var vPoaMgr;
PortableServer::ObjectId_var vDeactivatingObject;
ofstream fileOut;

// STARTUP
// General CORBA init
vOrb = CORBA::ORB_init(argc, argv);
vPoa = vOrb->resolve_initial_references("RootPOA");
vRootPoa = PortableServer::POA::_narrow(vPoa.in());
vPoaMgr = vRootPoa->the_POAManager();
vPoaMgr->activate();
// Init the CORBA object
vServer = servant._this();
// Write my IOR to a file so the client can read it
fileOut.open("ServerIOR");
fileOut << vOrb->object_to_string(vServer);
fileOut.close();

// RUN
cout << "Ready..." << endl;
vOrb->run();

// All done, go bye-bye
return 0;
} /* main() */

/*-- End Server_main.cpp --------------------------------------*/

===========================================================================

"Private Bytes" memory usage reported by Performance Monitor.
1st two columns are date/time stamps.
3rd column is client-side private bytes and 4th is the delta from one sec-
ond to the next. No leak here.
5th column is server-side private bytes and 6th is its delta.
I ran 8000 calls to PushAny(); based on this data I calculate ~1Kbyte of
leakage per call.
-----------------------------------------------------------
Reported on \\CCPC233
Date: 5/18/00
Time: 6:10:38 PM
Data: Current Activity
Interval: 1.000 seconds

Private Bytes Private Bytes
Any_leak_client Any_leak_server

Process Process
Date Time \\CCPC233 \\CCPC233
5/18/00 6:08:12PM
5/18/00 6:08:13P 0 0
5/18/00 6:08:14P 0 0 3137536 3137536
5/18/00 6:08:15P 0 0 3809280 671744
5/18/00 6:08:16P 0 0 3809280 0
5/18/00 6:08:17P 3747840 3747840 3809280 0
5/18/00 6:08:18P 3747840 0 3809280 0
5/18/00 6:08:19P 3756032 8192 4018176 208896
5/18/00 6:08:20P 3756032 0 4214784 196608
5/18/00 6:08:21P 3756032 0 4415488 200704
5/18/00 6:08:22P 3756032 0 4612096 196608
5/18/00 6:08:23P 3756032 0 4812800 200704
5/18/00 6:08:24P 3756032 0 4997120 184320
5/18/00 6:08:25P 3756032 0 5111808 114688
5/18/00 6:08:26P 3756032 0 5271552 159744
5/18/00 6:08:27P 3756032 0 5472256 200704
5/18/00 6:08:28P 3756032 0 5636096 163840
5/18/00 6:08:29P 3756032 0 5869568 233472
5/18/00 6:08:30P 3756032 0 6037504 167936
5/18/00 6:08:31P 3756032 0 6291456 253952
5/18/00 6:08:32P 3756032 0 6492160 200704
5/18/00 6:08:33P 3756032 0 6692864 200704
5/18/00 6:08:34P 3756032 0 6893568 200704
5/18/00 6:08:35P 3756032 0 7057408 163840
5/18/00 6:08:36P 3756032 0 7290880 233472
5/18/00 6:08:37P 3756032 0 7376896 86016
5/18/00 6:08:38P 3756032 0 7495680 118784
5/18/00 6:08:39P 3756032 0 7716864 221184
5/18/00 6:08:40P 3756032 0 7913472 196608
5/18/00 6:08:41P 3756032 0 8114176 200704
5/18/00 6:08:42P 3756032 0 8310784 196608
5/18/00 6:08:43P 3756032 0 8515584 204800
5/18/00 6:08:44P 3756032 0 8716288 200704
5/18/00 6:08:45P 3756032 0 8933376 217088
5/18/00 6:08:46P 3756032 0 9134080 200704
5/18/00 6:08:47P 3756032 0 9334784 200704
5/18/00 6:08:48P 3756032 0 9535488 200704
5/18/00 6:08:49P 3756032 0 9699328 163840
5/18/00 6:08:50P 3756032 0 9777152 77824
5/18/00 6:08:51P 3756032 0 9940992 163840
5/18/00 6:08:52P 3756032 0 10137600 196608
5/18/00 6:08:53P 3756032 0 10338304 200704
5/18/00 6:08:54P 3756032 0 10539008 200704
5/18/00 6:08:55P 3756032 0 10739712 200704
5/18/00 6:08:56P 3756032 0 10940416 200704
5/18/00 6:08:57P 3756032 0 11141120 200704
5/18/00 6:08:58P 3756032 0 11337728 196608
5/18/00 6:08:59P 3756032 0 11558912 221184
5/18/00 6:09:00P 3756032 0 11755520 196608
5/18/00 6:09:01P 3756032 0 11960320 204800
5/18/00 6:09:02P 3756032 0 12042240 81920
5/18/00 6:09:03P 3756032 0 12161024 118784
5/18/00 6:09:04P 3756032 0 12361728 200704
5/18/00 6:09:05P 3756032 0 12562432 200704
5/18/00 6:09:06P 3756032 0 12562432 0
5/18/00 6:09:07P 3756032 0 12562432 0
5/18/00 6:09:08P 0-3756032 12083200 -479232
5/18/00 6:09:09P 0 0 12083200 0
5/18/00 6:09:10P 0 0 0-1.2E+07
5/18/00 6:09:11P 0 0 0 0
-----------------------------------------------------------

===========================================================================

Finally, here is the BoundsChecker output. It reports many (64, w/ 28 al-
legedly from ACE/TAO code) other problems (dynamic memory overruns, call-
ing 'free' with bad handles, and memory and resource leaks) which don't get
worse with time but it's just too much data to include here. In addition,
I wouldn't be surprised to learn some of those are false positives.

Here are three memory leaks and one resource (CriticalSection) leak. Un-
fortunately some of the call trees are, I think, not much use because they
only apply to the last occurrance of each error.

--------------------------------------------------------------------------

[A null run (zero PushAny() calls made) leaves 107 of these. Each PushAny()
call adds 3 more. But the call stack doesn't look like it's from an up-
call...]

Memory leak
84 bytes allocated by operator new in T:\ACE_wrappers\TAO\tao\Typecode.cpp (143), HANDLE: 0x027E1130

Location of Error
CORBA_TypeCode::CORBA_TypeCode T:\ACE_wrappers\TAO\tao\Typecode.cpp 143
$E302 T:\ACE_wrappers\TAO\tao\DynAnyC.cpp 377
$E305 T:\ACE_wrappers\TAO\tao\DynAnyC.cpp 350
_initterm crt0dat.c 524
_CRT_INIT crtdll.c 184
_DllMainCRTStartup crtdll.c 267

--------------------------------------------------------------------------

[I get one of these per PushAny() call. And this call stack appears to
give useful context.]

Memory leak
8 bytes allocated by operator new in T:\ACE_wrappers\TAO\tao\Typecode.cpp (1544), HANDLE: 0x027FD030

Location of Error
CORBA_TypeCode::private_member_type T:\ACE_wrappers\TAO\tao\Typecode.cpp 1544
CORBA_TypeCode::member_type T:\ACE_wrappers\TAO\tao\Typecode.cpp 276
TAO_Marshal_Struct::skip T:\ACE_wrappers\TAO\tao\skip.cpp 314
TAO_Marshal_Object::perform_skip T:\ACE_wrappers\TAO\tao\Marshal.cpp 103
TAO_Marshal_Sequence::skip T:\ACE_wrappers\TAO\tao\skip.cpp 618
TAO_Marshal_Object::perform_skip T:\ACE_wrappers\TAO\tao\Marshal.cpp 118
TAO_Marshal_Alias::skip T:\ACE_wrappers\TAO\tao\skip.cpp 698
TAO_Marshal_Object::perform_skip T:\ACE_wrappers\TAO\tao\Marshal.cpp 128
TAO_Marshal_Union::skip T:\ACE_wrappers\TAO\tao\skip.cpp 552
TAO_Marshal_Object::perform_skip T:\ACE_wrappers\TAO\tao\Marshal.cpp 108
operator>> T:\ACE_wrappers\TAO\tao\Any.cpp 1632
POA_Test::Server::PushAny_skel E:\Home\tomz\misc\Test Program\Any_leak\ServerS.cpp 187
POA_Test::Server::_dispatch E:\Home\tomz\misc\Test Program\Any_leak\ServerS.cpp 416
TAO_Object_Adapter::dispatch_servant T:\ACE_wrappers\TAO\tao\Object_Adapter.cpp 277
TAO_GIOP_Message_Acceptors::process_client_request T:\ACE_wrappers\TAO\tao\GIOP_Message_Acceptors.cpp 173
TAO_GIOP_Message_Acceptors::process_client_message T:\ACE_wrappers\TAO\tao\GIOP_Message_Acceptors.cpp 32
TAO_IIOP_Server_Connection_Handler::handle_input_i T:\ACE_wrappers\TAO\tao\IIOP_Connect.cpp 331
TAO_IIOP_Server_Connection_Handler::handle_input T:\ACE_wrappers\TAO\tao\IIOP_Connect.cpp 275
ACE_Select_Reactor_T<ACE_Select_Reactor_Token_T<ACE_Token> >::notify_handle ../../ace/Select_Reactor_T.cpp 762
[Looks like more is missing from here?]

--------------------------------------------------------------------------

[I get 3 of these per PushAny() call. The call stack again appears val-
id.]

Memory leak
72 bytes allocated by operator new in T:\ACE_wrappers\TAO\tao\Typecode.cpp (2367), HANDLE: 0x027FD0B0

Location of Error
CORBA_TypeCode::_tao_decode T:\ACE_wrappers\TAO\tao\Typecode.cpp 2367
CORBA_TypeCode::private_member_type T:\ACE_wrappers\TAO\tao\Typecode.cpp 1633
CORBA_TypeCode::member_type T:\ACE_wrappers\TAO\tao\Typecode.cpp 276
TAO_Marshal_Union::skip T:\ACE_wrappers\TAO\tao\skip.cpp 548
TAO_Marshal_Object::perform_skip T:\ACE_wrappers\TAO\tao\Marshal.cpp 108
operator>> T:\ACE_wrappers\TAO\tao\Any.cpp 1632
POA_Test::Server::PushAny_skel E:\Home\tomz\misc\Test Program\Any_leak\ServerS.cpp 187
POA_Test::Server::_dispatch E:\Home\tomz\misc\Test Program\Any_leak\ServerS.cpp 416
TAO_Object_Adapter::dispatch_servant T:\ACE_wrappers\TAO\tao\Object_Adapter.cpp 277
TAO_GIOP_Message_Acceptors::process_client_request T:\ACE_wrappers\TAO\tao\GIOP_Message_Acceptors.cpp 173
TAO_GIOP_Message_Acceptors::process_client_message T:\ACE_wrappers\TAO\tao\GIOP_Message_Acceptors.cpp 32
TAO_IIOP_Server_Connection_Handler::handle_input_i T:\ACE_wrappers\TAO\tao\IIOP_Connect.cpp 331
TAO_IIOP_Server_Connection_Handler::handle_input T:\ACE_wrappers\TAO\tao\IIOP_Connect.cpp 275
ACE_Select_Reactor_T<ACE_Select_Reactor_Token_T<ACE_Token> >::notify_handle ../../ace/Select_Reactor_T.cpp 762
ACE_Select_Reactor_T<ACE_Select_Reactor_Token_T<ACE_Token> >::dispatch_io_set ../../ace/Select_Reactor_T.cpp 1033
ACE_Select_Reactor_T<ACE_Select_Reactor_Token_T<ACE_Token> >::dispatch_io_handlers ../../ace/Select_Reactor_T.cpp 1082
ACE_Select_Reactor_T<ACE_Select_Reactor_Token_T<ACE_Token> >::dispatch ../../ace/Select_Reactor_T.cpp 1175
ACE_Select_Reactor_T<ACE_Select_Reactor_Token_T<ACE_Token> >::handle_events_i ../../ace/Select_Reactor_T.cpp 1238
ACE_Select_Reactor_T<ACE_Select_Reactor_Token_T<ACE_Token> >::handle_events ../../ace/Select_Reactor_T.cpp 1220
[Looks like more is missing from here?]

--------------------------------------------------------------------------

[A null run leaves 217 of these. A run w/ only one PushAny() call yields
227, and a ten call run gives 281. I'm guessing we get 6 per call, with
the 1st call getting a few extra. This call stack doesn't look like an
upcall again...]

Resource leak: allocated by InitializeCriticalSection in ../ace/OS.i (2738), HANDLE: 0x007556F8

Location of Error
ACE_OS::thread_mutex_init ../ace/OS.i 2738
ACE_Thread_Mutex::ACE_Thread_Mutex T:\ACE_wrappers\ace\Synch.cpp 994
CORBA_TypeCode::CORBA_TypeCode T:\ACE_wrappers\TAO\tao\Typecode.cpp 143
$E221 T:\ACE_wrappers\TAO\tao\CONV_FRAMEC.cpp 57
$E224 T:\ACE_wrappers\TAO\tao\CONV_FRAMEC.cpp 47
_initterm crt0dat.c 524
_CRT_INIT crtdll.c 184
_DllMainCRTStartup crtdll.c 267

--------------------------------------------------------------------------

===========================================================================

Well, that's all :-) I've been working on these problems over a week and
haven't been able to track down even one. Maybe I'm too stuck in how I
would debug these things in an embedded system w/ an in-circuit emulator;
it seems like my techniques aren't transferring well to the PC despite the
debugger. Sometimes I think I could do better with a more basic debugger.

Since the above occur in 1.1.2 I figure the DOC Group might take a look at
them. Even if the BoundsChecker output isn't very helpful, it would be
good to see if you can reproduce the growing memory problem in general,
and perhaps what Purify reports. I'm downloading a demo copy of Purify to
see if it offers any more insight.

I don't even know with 100% confidence that the errors reported Bounds-
Checker are real. But something is certainly wrong somewhere.

FYI, I'm actually working mainly w/ TAO 1.1 because we're close to product
release and can't pick up a beta at this point. There are some other leaks
which I see 1.1 but not 1.1.2, and I'm working with OCI to address those.
In the meantime if any fixes for these leaks are identified in code which
also applies to 1.1, I can patch them into our build.

Thanks for any help you can provide.
Tom

Tom Z

unread,

May 18, 2000, 3:00:00 AM5/18/00

Tom Ziomek wrote:
>
> TAO VERSION: 1.1.2
> ACE VERSION: 5.1.2

[SNIP]

> The leak also occurs even if the server never performs an extraction from
> the Any.

Summary of the original leak report was
- No leak in client.
- Server leaks ~1 Kbyte per call, whether or not it actually extracts the
union from the passed-in Any.

Now this is interesting...I ran the leak demo code from my previous post w/
TAO 1.1. The server still leaked, but much more slowly -- ~69 bytes per
call when averaged over 10,000 calls. In addition, the client also leaked
at the exact same rate. So 1.1.2 fixes the client side but makes the ser-
ver side much worse.

In addition, when working w/ 1.1, if I change the server to not perform any
extraction from the Any, the server does NOT leak. So the "leak in server
even when not extracting" is new to 1.1.2 relative to 1.1.

My next step is to see if replacing the two sequences in my real IDL with
arrays is leak-free -- I'd rather do that than replace Any with an octet
sequence. After that I'll install Purify and see what it says about the
sequence-leak code.

Regards, Tom

Jeff Parsons

unread,

May 23, 2000, 3:00:00 AM5/23/00

Hi Tom,

There were indeed some memory leaks in TAO. I've just checked in
a fix that gets rid of the ones related to the union member (on
both the client and the server sides). Also, changing this method

>void Server_impl::Shutdown(void)
>{
> CORBA::ORB_init(m_argc, m_argv)->shutdown(FALSE);
>} /* Shutdown() */

to this

void Server_impl::Shutdown(void)
{
CORBA::ORB_var orb = CORBA::ORB_init (m_argc, m_argv);
orb->shutdown (FALSE);
} /* Shutdown() */

got rid of some more leaks ;-). There were still some leaks remaining
in Purify related to ORB initialization (resolve_initial_references
on the root POA) that I will pass along to our POA guru, but these
may be bogus. And finally, this output

Memory leak
84 bytes allocated by operator new in T:\ACE_wrappers\TAO\tao\Typecode.cpp
(143), HANDLE: 0x027E1130

that you sent is very mystifying, your code is not using any DynAny
stuff at all, nor is it used internally in TAO. Anyway, your example
code was great and really helped to track this down quickly. As always,
thanks for sending it in!

--
Jeff Parsons <par...@cs.wustl.edu>
"One kind of soap to wash and another kind
to shave? Life is too complicated." - Albert Einstein

Jeff Parsons

unread,

May 23, 2000, 3:00:00 AM5/23/00

Hi Tom,

Just FYI, making these changes to your server main() gets rid of
the rest of the memory leaks (I did some more playing around after my
last email to you).

// Write my IOR to a file so the client can read it
fileOut.open("ServerIOR");

CORBA::String_var obj_str =
vOrb->object_to_string (vServer.in ()); <------
fileOut << obj_str.in ();
fileOut.close();

// RUN
cout << "Ready..." << endl;
vOrb->run();

// All done, go bye-bye

vRootPoa->destroy (1, 1); <------

return 0;
} /* main() */

Tom Z

unread,

May 24, 2000, 3:00:00 AM5/24/00

Jeff Parsons wrote:
>
> Hi Tom,
>
> There were indeed some memory leaks in TAO. I've just checked in
> a fix that gets rid of the ones related to the union member (on
> both the client and the server sides).

Cool, thanks.

I'd been hoping that I could apply the same or similar changes to our 1.1
source code but seeing how much append.cpp and skip.cpp have changed that
won't be possible.

Though your note about the leaks being in the union marshalling help confirm
our workaround (Our application passes to the union to some CORBA-hiding
wrappers, which were putting the union into the Any. Our workaround is to,
in the wrapper, take the info back OUT of the union and insert it into the
Any directly. And of course the reverse on the delivery side).

>Also, changing this method
>
> >void Server_impl::Shutdown(void)
> >{
> > CORBA::ORB_init(m_argc, m_argv)->shutdown(FALSE);
> >} /* Shutdown() */
>
> to this
>
> void Server_impl::Shutdown(void)
> {
> CORBA::ORB_var orb = CORBA::ORB_init (m_argc, m_argv);
> orb->shutdown (FALSE);
> } /* Shutdown() */
>
> got rid of some more leaks ;-).

Yeah, the latter is what our real code does anyway.

>There were still some leaks remaining
> in Purify related to ORB initialization (resolve_initial_references
> on the root POA) that I will pass along to our POA guru, but these
> may be bogus.

Yeah, I have the same feeling with respect to possible bogosity
( http://www.tuxedo.org/~esr/jargon/html/entry/bogosity.html ) of the
leak reports.

>Anyway, your example
> code was great and really helped to track this down quickly. As always,
> thanks for sending it in!

You're welcome [Thanks for fixing it!]. Reducing something down to a sim-
ple example takes a while but I figure is worth it in giving you something
you can easily get traction on.

Mary Jones

unread,

Oct 29, 2023, 7:11:24 PM10/29/23

Mary Jones

unread,

Oct 29, 2023, 7:20:28 PM10/29/23

0 new messages