Hello.
I started to work on some project which uses xerces 2.8.0.
What I need to fix is memory leak. I already tackled memory caused in
our source codes.
However, bigger part of memory is found on xerces codes. At every a few
seconds, it eats 92KBytes to 110 KBytes additionally. I found out that
it was caused by some codes around xerces.
First I checked if our codes follow xerces memory management style.
Whenever things are retrieved by Create...() function, they are
destroyed using release(). xerces objects are created with new and
deallocated with delete. No problem in that pattern. Objects returned by
getDocumentElement() are not released explicitly because it is owned by
xerces object. So, things look good.
however, what I found out was that when the release() is called and a
new object is created, instead of using memory pool which is some space
due to the release(), it allocates new memory space, and it keeps being
accumulated. I confirmed that the released memory space is marked with
0xEE FE. So, release() works. However, it should collect the freed
memory space periodically, but it doesn't seem to.
I know xerces don't use actual garbage collection. This kind of memory
management is pseudo garbage collection or retain count-based memory
management. So, the memory pool should be cleaned up by some other
objects or it should provide some functions to clean up memory pool
explicitly, but didn't find any such functions yet.
Can someone help me to solve this problem?
I would like to add some codes here to give some idea.
class CDocOut
{
public:
CDocOut(DOMImplementation* impl, DOMWriter* serializer);
public:
virtual ~CDocOut(void);
public:
void AddEnvelope(const char* name);
void AddTextElement(const char* name,const char* text);
char* Serialize(int* len);
protected:
DOMImplementation* m_impl;
DOMWriter* m_serializer;
XMLFormatTarget* m_formatTarget;
DOMDocument* doc_out;
DOMElement* root;
DOMElement* current;
};
CDocOut::CDocOut(DOMImplementation* impl, DOMWriter*
serializer):m_impl(impl),m_serializer(serializer)
{
m_formatTarget=new MemBufFormatTarget;
//doc_out = m_impl->createDocument(0,
XMLSTR("LogoMessageSequence"), 0);
doc_out = m_impl->createDocument(0, XMLSTR("LogoRequestMessage"), 0);
// root and current will not needed to be "release()"ed because it
is obtained by get... function.
root = doc_out->getDocumentElement();
current=root;
current->setAttribute(XMLSTR("xmlns"),XMLSTR("http://(some
address)/bcd/programs/DTVINABOX/LogoControlProtocol.xsd"));
}
// In this destructor, I could confirm that all the memory spaces are
marked with 0xEEFE,
// but process monitor didn't display that the memory usage was actually
going down.
// I assume that the actual memory free can be delayed though, but over
12hours
CDocOut::~CDocOut(void)
{
// I expect this line will release the memory space pointed by
// m_formatTarget->getRawBuffer(); in Serializer() below.
// And actually it is. The memory space pointed by that is marked
with 0xEEFE
delete m_formatTarget;
if(doc_out!=NULL)
doc_out->release(); // because doc_out was created using
CreateDocument(), it needs release().
// So, I could confirm that it marked its memory space "deallocated".
// However, it doesn't actually "free" the memory.
}
void CDocOut::AddEnvelope(const char* name)
{
DOMElement* e1 = doc_out->createElement(XMLSTR(name));
current->appendChild(e1);
current=e1;
}
void CDocOut::AddTextElement(const char* name,const char* text)
{
DOMElement* e1 = doc_out->createElement(XMLSTR(name));
current->appendChild(e1);
DOMText* t1=doc_out->createTextNode(XMLSTR(text));
e1->appendChild(t1);
}
char* CDocOut::Serialize(int* len)
{
char* buf;
// Noticed memory usage went up here.
// So, it seems to me that xerces allocates more memory space at will
for this writeNode() call
m_serializer->writeNode(m_formatTarget, *doc_out);
buf = (char*)((MemBufFormatTarget*)m_formatTarget)->getRawBuffer();
*len=((MemBufFormatTarget*)m_formatTarget)->getLen();
return buf;
}
So, is there something wrong in above codes? or is there a way to say it
to free the memory actually?
Thank you.
JongAm Park
--
JongAm Park
[email protected]
Visit my personal blog at http://jongampark.blogspot.com
Visit my technical blog at http://jongampark.wordpress.com
