Re: Is this a memory leak?

This is not a memory leak. Please let me
explain why and where the memory is released.



The object holding the memory created
through _rep = new CIMInstanceRep() is CIMInstance
indInst;

That object is placed on the stack,
meaning on leaving function mbDeliverIndication() in CMPIBroker.cpp the
destructor of it is called.

The destructor of CIMInstance does call
Dec(_rep) which is inherited from class CIMObjectRep.

void Dec()

{

if (_refCounter.decAndTestIfZero())


delete this;

}

and here the internal representation
of object CIMInstanceRep is deleted.



If you see memory growing on indication
providers, a common mistake made by CMPI provider writers is not to release
instances delivered while delivering instances through a separate thread
created by the provider for that purpose. Calling CMReleaseInstance() after
each CMDeliverInstance() will help the CIM Server to release that memory
early.





Mit freundlichen Grüßen / Kind regards

Marek Szermutzky



Software Engineer / OpenPegasus Maintainer (PMC) and z/OS PlatformRep.

IBM Systems &Technology Group, Systems Software Development / z/OS
Capacity Management and Support

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

IBM Deutschland

Schoenaicher Str. 220

71032 Boeblingen

Phone: +49-7031-16-5182

E-Mail: [email protected]

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

IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats:
Martin Jetter

Geschäftsführung: Dirk Wittkopp

Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart,
HRB 243294 







From: 
"Hwang, Johnny"
<[email protected]>

To: 
"[email protected]"
<[email protected]>

Date: 
19.09.2012 10:07

Subject: 
Is this a memory
leak?



----------






This is in src/Pegasus/ProviderManager2/CMPI/CMPI_Broker.cpp,
circa line 900. 



static CMPIStatus mbDeliverIndication(

const CMPIBroker*
eMb,

const CMPIContext*
ctx,

const char
*ns,

const CMPIInstance*
ind)

{

PEG_METHOD_ENTER(


TRC_CMPIPROVIDERINTERFACE,


"CMPI_Broker:mbDeliverIndication()");

// If no valid
broker was passed in we try the use the broker

// that was
stored in the local thread context

if (eMb==NULL)

{

eMb = CM_BROKER;

}

CMPI_Broker
*mb = (CMPI_Broker*)eMb;

IndProvRecord
*indProvRec;

OperationContext*
context = CM_Context(ctx);



SCMOInstance*
scmoInst = SCMO_Instance(ind);

CIMInstance
indInst;

scmoInst->getCIMInstance(indInst);
//*** <- IS THIS A MEMORY LEAK?!?!? Does this guy need to be freed
explicitly? getCIMInstance() calls new() in its stack.***



…

PEG_METHOD_EXIT();

CMReturn(CMPI_RC_ERR_FAILED);

}

}





This is my valgrind feed:

> ==14407== 71,088 bytes in 1,481 blocks
are possibly lost in loss record 4,369 of 4,489

> ==14407== at 0x4C710D5:
operator new(unsigned int) (vg_replace_malloc.c:214)

> ==14407== by 0x7A65AAE:
Pegasus::CIMInstanceRep::clone() const (CIMInstanceRep.h:64)

> ==14407== by 0x7A81101:
Pegasus::CIMObject::clone() const (CIMObject.cpp:229)

> ==14407== by 0x7AA5A0F:
Pegasus::CIMValue::set(Pegasus::CIMObject const&) (CIMValue.cpp:797)

> ==14407== by 0x7A22575:
Pegasus::SCMOInstance::_getCIMValueFromSCMBUnion(Pegasus::CIMValue&,
Pegasus::CIMType, bool, bool, unsigned int, Pegasus::SCMBUnion const&,
char const*) (SCMO.cpp:2175)

> ==14407== by 0x7A22919:
Pegasus::SCMOInstance::_getCIMValueFromSCMBValue(Pegasus::CIMValue&,
Pegasus::SCMBValue const&, char const*) (SCMO.cpp:2244)

> ==14407== by 0x7A22BEC:
Pegasus::SCMOInstance::_getCIMPropertyAtNodeIndex(unsigned int) const (SCMO.cpp:1747)

> ==14407== by 0x7A23B1A:
Pegasus::SCMOInstance::getCIMInstance(Pegasus::CIMInstance&) const
(SCMO.cpp:1633)

> ==14407== by 0xC0CE632:
mbDeliverIndication (CMPI_Broker.cpp:928)

> ==14407== by 0xC12BD14:
sendIndicationFunction (x.c:x)<- this line reads "pBrk->bft->deliverIndication(pBrk,
pCtx, pNamespace,…)"

> ==14407==



I have nowhere near 1481 indication items
to process. More in the order of low hundreds, run for several cycles.
Therefore, this is not an individual cycle, but continuously piled up over
time and is most likely a leak. 



Thanks for understanding,

Johnny Hwang