[omniORB] Memory leaks

[Aida Fátima Cano]

Hello

When I stop my application, running under windows 2000, the Microsoft Visual
C++ logs the following info debug (I have paste just some lines of it).

My code never pass trough "orb->destroy()". Could it be the cause of the
memory leaks?

Can I do something not to have these?

I have read other questions in this list about memory leaks, but I can't see
how to solve my problem.

Thanks


Creation of the CORBA thread:

DWORD WINAPI HiloCorba(void *Param)
{
CORBA::ORB_var orb;

try
{


//------------------------------------------------------------------------
// Initialize CORBA ORB - "orb"

//------------------------------------------------------------------------
int argc=0; // Dummy variables to support following call.
char** argv=0;

orb = CORBA::ORB_init(argc, argv);


//------------------------------------------------------------------------
// Servant must register with POA in order to be made available for
client
// Get reference to the RootPOA.

//------------------------------------------------------------------------
CORBA::Object_var obj = orb->resolve_initial_references("RootPOA");
PortableServer::POA_var _poa = PortableServer::POA::_narrow(obj.in());



//------------------------------------------------------------------------
// Operations defined in object interface invoked via an object
reference.
// Instance of CRequestSocketStream_i servant is initialized.

//------------------------------------------------------------------------
CDT_CS_Request_i* myInfoRequest= new CDT_CS_Request_i();


//------------------------------------------------------------------------
// Servant object activated in RootPOA.
// (Object id used for various POA operations.)

//------------------------------------------------------------------------
PortableServer::ObjectId_var myInfoRequest_oid =
_poa->activate_object(myInfoRequest);



//------------------------------------------------------------------------
// Obtain object reference from servant and register in naming
service(??)

//------------------------------------------------------------------------
CORBA::Object_var SA_obj = myInfoRequest->_this();



//------------------------------------------------------------------------
// Obtain a reference to the object, and print it out as string IOR.

//------------------------------------------------------------------------
CORBA::String_var sior(orb->object_to_string(SA_obj.in()));
cerr << "'" << (char*)sior << "'" << endl;



//------------------------------------------------------------------------
// Bind object to name service as defined by directive InitRef
// and identifier "NameService" in config file omniORB.cfg.

//------------------------------------------------------------------------
CORBA::Object_var obj1=orb->resolve_initial_references("NameService");
assert(!CORBA::is_nil(obj1.in()));



//------------------------------------------------------------------------
// narrow this to the naming context

//------------------------------------------------------------------------
CosNaming::NamingContext_var nc = CosNaming::NamingContext::_narrow(
obj1.in());
assert(!CORBA::is_nil(nc.in()));



//------------------------------------------------------------------------
// Bind to CORBA name service. Same name to be requested by client.

//------------------------------------------------------------------------
CosNaming::Name name;
name.length(1);
name[0].id=CORBA::string_dup("DispatcherServiceServ");
nc->rebind (name,SA_obj.in());



myInfoRequest->_remove_ref();



//------------------------------------------------------------------------
// Activate the POA manager

//------------------------------------------------------------------------
PortableServer::POAManager_var pmgr = _poa->the_POAManager();
pmgr->activate();



//------------------------------------------------------------------------
// Accept requests from clients

//------------------------------------------------------------------------
orb->run();


//------------------------------------------------------------------------
// If orb leaves event handling loop.
// - currently configured never to time out (??)

//------------------------------------------------------------------------
orb->destroy();


free(name[0].id); // str_dup does a malloc internally*/
}

catch(CORBA::SystemException&) {
cerr << "Caught CORBA::SystemException." << endl;
}
catch(CORBA::Exception&)
{
cerr << "Caught CORBA::Exception." << endl;
}
catch(omniORB::fatalException& fe) {
cerr << "Caught omniORB::fatalException:" << endl;
cerr << " file: " << fe.file() << endl;
cerr << " line: " << fe. line() << endl;
cerr << " mesg: " << fe.errmsg() << endl;
}
catch(...) {
cerr << "Caught unknown exception." << endl;
}
return 0;
}




MEMORY LEAKS

Detected memory leaks!
Dumping objects ->
{2907} normal block at 0x0092C500, 100 bytes long.
Data: < p g > 1C 70 C1 67 10 C5 14 00 FF FF FF FF 00 00 00 00
{2889} normal block at 0x0092C300, 228 bytes long.
Data: <8 g JBOC g> 38 E6 D0 67 00 00 00 00 4A 42 4F 43 0C E6 D0 67
{2815} normal block at 0x0092B728, 4 bytes long.
Data: <h > 68 C2 92 00
plex.cpp(31) : {2807} normal block at 0x0092BFE8, 124 bytes long.
Data: < > 00 00 00 00 00 00 00 00 04 00 CC 00 08 BF 92 00
map_pp.cpp(72) : {2806} normal block at 0x0092BF60, 68 bytes long.
Data: < > EC BF 92 00 00 00 00 00 00 00 00 00 00 00 00 00
{2805} client block at 0x0092BF08, subtype 0, 20 bytes long.
a CInternetSession object at $0092BF08, 20 bytes long
{2803} normal block at 0x0092BDF8, 100 bytes long.
Data: < XF XF cF > B4 58 46 00 D0 58 46 00 CD CD CD CD D8 63 46 00
{2790} normal block at 0x0092B7D8, 16 bytes long.
Data: < 3 @4 > 00 33 92 00 40 34 92 00 84 B7 92 00 00 C3 92 00
{2789} normal block at 0x0092B770, 32 bytes long.
Data: < g g > 04 E8 D0 67 14 E8 D0 67 00 00 00 00 00 00 00 00
{2785} normal block at 0x00927380, 12 bytes long.
Data: <TSQS e g> 54 53 51 53 01 00 00 00 18 65 D9 67
{2783} normal block at 0x0092B868, 14 bytes long.
Data: <192.168.2.114 > 31 39 32 2E 31 36 38 2E 32 2E 31 31 34 00
{2760} normal block at 0x00927338, 4 bytes long.
Data: < p > 98 70 92 00
{2616} normal block at 0x00926FF8, 12 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00
{2610} normal block at 0x00926E08, 24 bytes long.
Data: < > 00 B4 14 00 FF FF FF FF 00 00 00 00 00 00 00 00
{2603} normal block at 0x00926DA0, 32 bytes long.
Data: < > 01 00 00 00 01 00 01 00 01 00 00 00 01 00 01 05
{2597} normal block at 0x00926BC0, 24 bytes long.
Data: < > C8 B3 14 00 FF FF FF FF 00 00 00 00 00 00 00 00
{2587} normal block at 0x00926588, 24 bytes long.
Data: < > 20 B3 14 00 FF FF FF FF 00 00 00 00 00 00 00 00
{2586} normal block at 0x00926530, 24 bytes long.
Data: < > E8 B2 14 00 FF FF FF FF 00 00 00 00 00 00 00 00
{2585} normal block at 0x00925098, 24 bytes long.
Data: < > B0 B2 14 00 FF FF FF FF 00 00 00 00 00 00 00 00
{2583} normal block at 0x009264E8, 4 bytes long.
Data: < d > 90 64 92 00
{2573} normal block at 0x009220E0, 4 bytes long.
Data: < > 88 20 92 00
{2562} normal block at 0x00925280, 8 bytes long.
Data: <H (R > 48 1E 92 00 28 52 92 00
{2561} normal block at 0x00925228, 17 bytes long.
Data: <127.0.0.1 > 31 32 37 2E 30 2E 30 2E 31 00 CD CD CD CD CD CD
{2559} normal block at 0x00921E48, 17 bytes long.
Data: <192.168.2.114 > 31 39 32 2E 31 36 38 2E 32 2E 31 31 34 00 CD CD
{2552} normal block at 0x00923440, 12 bytes long.
Data: <h g JBOC> 68 D0 D0 67 00 00 00 00 4A 42 4F 43
{2475} normal block at 0x00925168, 37 bytes long.
Data: <NameService=corb> 4E 61 6D 65 53 65 72 76 69 63 65 3D 63 6F 72 62
{2474} normal block at 0x00925120, 12 bytes long.
Data: < g ghQ > E8 67 D9 67 68 51 92 00 02 00 00 00
{2471} normal block at 0x00924FF8, 2 bytes long.
Data: <1 > 31 00

(...)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070227/4e70bace/attachment-0001.htm

[Duncan Grisby]

Post by Aida Fátima Cano
When I stop my application, running under windows 2000, the Microsoft Visual
C++ logs the following info debug (I have paste just some lines of it).
My code never pass trough "orb->destroy()". Could it be the cause of the
memory leaks?

If you don't call orb->destroy(), you will have large numbers of leaks.
Once you've called destroy(), you shouldn't see any leaks due to
omniORB.

Cheers,

Duncan.

[Aida Fátima Cano]

--------------------------------------------------------------------------
// If orb leaves event handling loop.
// - currently configured never to time out (??)
//------------------------------------------------------------------------
orb->destroy();

I'm trying to call orb->destroy(), but it seems I can't call it from another
thread. How can I configure orb to leaves handling loop when the application
is going to stop?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070227/66387a7b/attachment.htm

[Aida Fátima Cano]

It is normal that, after calling orb->destroy(),
orb->pd_ref->[omniORB]->pd_refCount equals 1 ?

I have call orb->shutdown, then orb->run has exited and after that the
thread calls orb->destroy(), but there are still memory leaks.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070227/9c444e2e/attachment.htm

[Duncan Grisby]

Post by Aida Fátima Cano
I'm trying to call orb->destroy(), but it seems I can't call it from another
thread. How can I configure orb to leaves handling loop when the application
is going to stop?

Call orb->shutdown(0) from another thread.

[Duncan Grisby]

Post by Aida Fátima Cano
It is normal that, after calling orb->destroy(),
orb->pd_ref->[omniORB]->pd_refCount equals 1 ?

If the refCount is 1, that means you are still holding a reference to
it, so it has not been deleted. It has been destroyed, meaning it is no
longer operative, and all the threads and so on have stopped, but the
C++ ORB object cannot be deleted until all references are released.

You should use a _var type to hold the ORB reference, like this:

CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);

then when the variable goes out of scope, the reference count will be
decremented and the C++ objects can be deleted (assuming you haven't
leaked a reference anywhere else).

Cheers,

Duncan.