Open GoogleCodeExporter opened 8 years ago
One more details: it seem tinyxml allocate a new "wrapper" object every time it
call
NextSiblingElement or FirstChildElement which is weird ! is this normal ?
Original comment by alainfa...@gmail.com
on 26 Mar 2009 at 8:21
looking to the code of TiXml++ in ticpp.h/cpp
I found this:
a wrapper is created and added to (spawnedWrappers) each time a sibling is
created
this vector will be bigger and bigger !
>> ticpp.cpp
Element* temp = new Element( sibling );
sibling->m_spawnedWrappers.push_back( temp );
is this normal ? no way to use only one wrapper or a map of wrapper ? to avoid
memory
overflow in case of multiple access before closing the document.
Original comment by alainfa...@gmail.com
on 26 Mar 2009 at 12:47
Hi! Is this related with issue 42?
Original comment by sukend...@gmail.com
on 24 Mar 2011 at 11:02
Seem no update for this issue, I meet this problem now. before XML doc is
closed, memory is keep raising. seems no way to free then dynamicly.
Original comment by go.aa.h...@gmail.com
on 9 Nov 2011 at 2:27
Hi,
Did anyone find a resolution to the memory leak issue? Please update the thread
incase anyone has a solution.
Thanks
Original comment by shomadi...@gmail.com
on 21 Oct 2013 at 10:17
The workaround I found is to precharge the items I need from the xml at the
begin of the program only once !!
Regards
Alain
Original comment by alainfa...@gmail.com
on 22 Oct 2013 at 11:20
Hi Alain,
I am sorry, I did not get what you meant by precharge the items. Is there no
code fix for this issue? It will be nice to have a small example of the
workaround. Issue 61 also looks similar but there is no solution mentioned
anywhere.
Thanks,
Adi
Original comment by shomadi...@gmail.com
on 25 Oct 2013 at 9:27
the leak is reported in the following manner:
/utilTinyXml.dll!ticpp::Document::Parse
/utilTinyXml.dll!TiXmlDocument::Parse
/utilTinyXml.dll!TiXmlElement::Parse
/utilTinyXml.dll!TiXmlElement::ReadValue
/utilTinyXml.dll!TiXmlElement::Parse
/utilTinyXml.dll!TiXmlElement::ReadValue
/utilTinyXml.dll!TiXmlElement::Parse
/utilTinyXml.dll!TiXmlElement::ReadValue
/utilTinyXml.dll!TiXmlElement::Parse
/utilTinyXml.dll!TiXmlElement::ReadValue
/utilTinyXml.dll!TiXmlElement::Parse
/utilTinyXml.dll!TiXmlElement::ReadValue
/utilTinyXml.dll!TiXmlElement::Parse
/utilTinyXml.dll!TiXmlElement::ReadValue
/msvcr100_clr0400.dll!operator new
/msvcr100_clr0400.dll!malloc
/ntdll.dll!RtlAllocateHeap
/ntdll.dll!RtlpLowFragHeapAllocFromContext
/ntdll.dll!RtlpAllocateUserBlock
/ntdll.dll!RtlAllocateHeap
/ntdll.dll!RtlpAllocateHeap
/ntdll.dll!RtlpExtendHeap
/ntdll.dll!RtlpFindAndCommitPages
/ntdll.dll!ZwAllocateVirtualMemory
/ntkrnlmp.exe!KiSystemServiceCopyEnd
/ntkrnlmp.exe! ?? ::NNGAKEGL::`string'
Original comment by shomadi...@gmail.com
on 25 Oct 2013 at 9:35
in my application, I have an xml that contains a certain number of parameters.
I preload those parameters ones upon initialization and store them into
variables.
I do not have to read them more then one.
Regards
Alain
Original comment by alainfa...@gmail.com
on 25 Oct 2013 at 2:00
See my comment(#7) to issue 42
Original comment by rldu...@gmail.com
on 17 May 2014 at 10:42
I don't believe this is at all related to issue 42. That seems to be a
misunderstanding about how the reference counting works when using
LinkEndChild().
This issue seems be caused by the method of how the wrappers generated and
stored. Memory is still cleaned up when the document is destroyed. However, in
an application where the document object has a long lifetime and is repeatedly
accessed through functions such as FirstChildElement(), memory will
continuously build up. I don't see a reason why FirstChildElement() needs to
create a new wrapper each time it's called. All of them would be pointing to
the same object. Instead of having a container such as:
std::vector< ticpp::Base* > m_spawnedWrappers
why not just have each TiXmlBase object (through it's base class TiCppRC) just
contain a pointer to its own wrapper (created only when needed)? Maybe I am
missing an obvious reason for this. Can someone explain the reason for a
container? Thanks,
Ryan
Original comment by ryan.da...@gmail.com
on 4 Feb 2015 at 3:43
Original issue reported on code.google.com by
alainfa...@gmail.com
on 25 Mar 2009 at 11:57