booya55 at July 24th, 2011 19:37 — #1
We have a program that loads and parses 3 plist files.
However, we are gettng memory errors for certain plist files.
We have attached our sample program.
Sample program explanation:
In BBB.cpp, we are loading three plist’s 20.plist, 30.plist, 45.plist
20.plist loads 20 images, 30.plist load 30 images and so forth.
20.plist and 30.plist works fine. However, when loading/parsing 45.plist we get a memory error.
We would like to know if there is a limit or if this is an engine bug.
Lastly, in the icf file, we set the MemFlags0=USE_STACK_ALLOCATOR option. When doing so, the loading works fine but there is a memory leak. If we don’t have this option then the loading/parsing doesn’t work correctly for 45.plist.
We have attached the sample program below. If you can please take a look and give us some insight into this problem, we’d greatly appreciate it. Thank you.
booya55 at July 24th, 2011 19:39 — #2
I’m having trouble uploading the sample project so please download it from here:
axmx at July 26th, 2011 08:35 — #3
mmm… I set in the “BBB.cpp” CCSpriteFrameCache::sharedSpriteFrameCache()~~>addSpriteFramesWithFile~~ test loaded and started without “leak errors” …
zhangbin at September 7th, 2011 20:08 — #4
Thanks for your feedback. And sorry for our lated reply.
Issue #712 created for this problem.
vegasfbi at September 8th, 2011 10:30 — #5
I have noticed this same behaviour and was debugging last weekend. It seemed to be failing to allocate memory in the xmlparser code, although it doesn’t appear to happen all the time. When it was in error the value it was trying to allocate was way more than it should have been. I’ll try to debug some more this weekend.
w1nt3r at November 30th, 2011 21:37 — #6
Hi all! I was able to replicate the same issue on marmalade simulator (VS2008, Win XP SP3). Calling CCSpriteFrameCache::sharedSpriteFrameCache()->addSpriteFramesWithFile(“45.plist”) second time after I switching to another scene and back cause malloc fail.
HelloWorld.s86!STL::_malloc_alloc<0>::allocate(unsigned int __n=256295477) Line 110 + 0x9 bytes C++
Why does addSpriteFramesWithFile need more than 256 295 477 bytes??? It seems there is some bug in XML parser. Like missed bytes_to_allocate=0 or something similar… Did anyone find solution?
vegasfbi at December 1st, 2011 03:11 — #7
I’m not sure if this is related but it seems like Maramalade doesn’t use libxml2 but the other platforms here do, such as android and win32.
Since libxml2 is available for Maramalade also (https://github.com/marmalade) I have integrated it into cocos2d-x following the android project as an example.
I wish we had someone that had more time to support Maramalde here but that doesn’t seem the case so I’ll put my few hours in here and there when I can.
w1nt3r at December 1st, 2011 03:34 — #8
I investigated this a little bit and found that cocos2d-x for Marmalade is using expat free parser http://sourceforge.net/projects/expat/. Regarding heap error I found that plist should be in UTF-8. I also removed all spaces and LF’s from plist and this fixed the issue with allocating memory in heap while parsing plist file. And I discovered that not all plists can be parsed by expat. Some complicated ones are causing memory error.
Hope this can help.
vegasfbi at December 4th, 2011 15:49 — #9
I was able to swap out expat for libxml2 and the above PlistTest.zip worked fine for all the included plists, including the 45.plist. Suprisingly there were not many changes that needed to be made, the hardest part was getting the libxml2 to link and that just turned out to be a header inclusion problem.
I ran through most of the tests in cocos2d-x, the Zwoptex Test worked fine. Not sure what other tests need to be done to verify everything is working.
Tested the deployment on the Kindle Fire since it is easier to deploy to than my iPad (my certificates are all messed up and I need to sort it out)
phuongitbk at June 17th, 2013 04:50 — #10
I have the same issue in cocos2dx 2.0 for windows phone 8. Please let me know how to resolve this problem?
Thanks so much.