radada ha scritto:
Ouh, no answers so far...
Should I just give up?
No, you should just delete all the items in the vector
DocumentXML::m_oListeElementXML in the destructor, just before invoking
m_oListeElementXML.clear()
Alberto
Thanks.
radada wrote:
Hi Alberto and as always, thanks for your answer.
God I'm lame :D:D I didn't see that I dod not released the XMLCh in the
GetFlux method.
However, even with this, I still get a memroy leak. I joined the log so
that you can see bay yourself the results of the ps command -->
http://www.nabble.com/file/p23478308/log.zip log.zip
The strangest thing is that, when I delete and release all the objects at
the end of the program`(i.e. release of the factory), the memory still
grows :
Conso MEMOIRE AVANT RELEASE FACTORY
PID TTY STAT TIME PGIN SIZE RSS LIM TSIZ TRS %CPU %MEM
COMMAND
28476 pts/2 A 0:18 419 3884 4576 32768 125 692 2.5 0.0
batchJTO
XMLFactory::releaseFactory()
Destructeur de XMLFactory
bJTOTest::afficherMemoire()
Conso MEMOIRE APRES RELEASE FACTORY
PID TTY STAT TIME PGIN SIZE RSS LIM TSIZ TRS %CPU %MEM
COMMAND
28476 pts/2 A 0:18 432 3932 4624 32768 125 692 2.5 0.0
batchJTO
I really don't know what's happening...
The memory leak could seem small, but when I use this code inside the
whole package, I really get a strong memory leak.
I hope you'll find a little bit more time to check this code. If you can't
or don't see something obvious, I'll throw in the towel :-((
Alberto Massari wrote:
A few points that I noticed by reading the code:
1) in ElementXML::rechercherValeurAttribut you call
XMLString::release(&l_poValue), but l_poValue comes from a call to
m_poDOMElement->getAttribute, and should not be released
2) DocumentXML::getFlux doesn't release the l_poString string allocated
by writeToString
3) DocumentXML::getFlux stores the result of the serialization in a
char* m_pcBuffer that is not deleted in the destructor for DocumentXML;
it destroys a previous buffer if called twice on the same object, but it
will not clean the last serialization output
Alberto
radada ha scritto:
There you go : http://www.nabble.com/file/p23421942/batch.tar.gz
batch.tar.gz , and as always : thanks a lot :-D
Alberto Massari wrote:
Could you post your code in a more standard format, like tar.gz?
Thanks,
Alberto
radada ha scritto:
Hi there (again :-()
It may be a little bit long, so I'd like to apologize first.
I'm trying (for my work) to add a functional layer to the xerces
library
so
that other developers can use it by calling some more functional
methods.
The point is also to raise some particular type of exception so that
it
can
be easily reused.
When I directly implement some code to create a small XML file (see
previous
posts), it works perfectly. All my objects are released, and I'm
happy.
(the
code is here http://www.nabble.com/file/p23402427/bjtotestGood.cxx
bjtotestGood.cxx )
But I try to encapsulate that into a more functional way, I get a
memory
leak.
First I though of doing some nice Oriented Object Programming and
subclass
some of the xerces objects (DOMElement and DOMDocument especially),
but I
found out that these classes are pure virtual classes and I can't
subclass
them without redefining all the pure virtual methods.
I tried to subclass the implementation objects (i.e. DOMElementImpl
and
DOMDocumentImpl) but I'm stuck with all the Factories and Singeltons
(DOMIplementation and DOMIplementationRegirsty mainly).
So I decide to create some functional objects from scratch (XMLElement
and
XMLDocument) that would not inherit from DOMElement and DOMDocument,
but
have theses objects as members of my classes. But when I do that, and
I
re-implement the small program to generate some small XML files, I get
a
memory leak... I just don't understand, since I do exactly the same
thing
that I was doing first. I joined the source code here so that, if you
feel
willing to help, you can get the code :
http://www.nabble.com/file/p23402427/batchTest.rar batchTest.rar
I cleaned the code (we use several libraries) so that it could compile
and
run on any (i hope) UNIX server. I run it on an AIX 5.1
Thanks a lot if you got here, and thanks a lot in advance for your
help.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
