Hi Alberto, why should I explicitly call the destructor of the item when the clear method already does it?
All the elements of the vector are dropped: their destructors are called, and then they are removed from the vector container, leaving the container with a size of 0. Is it because the clear method only removes the elements from the vector w/o calling the destructor? I'll try it just to be sure. Check back soon : ) Alberto Massari wrote: > > 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] > > > -- View this message in context: http://www.nabble.com/Memory-leak-over-and-over...-tp23402427p23502127.html Sent from the Xerces - C - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
