I have downloaded the finished sample project which can be downloaded here http://www.raywenderlich.com/downloads/Cocos2DSimpleGame3_v2.zip
from Ray Wenderlichs tutorial site http://www.raywenderlich.com/25806/harder-monsters-and-more-levels-how-to-make-a-simple-iphone-game-with-cocos2d-2-x-part-3
I have put it on my device and noticed that my iphone memory got full after a while. I used xcode to test for memory leaks (product -> profile) and it showed that there are numerous memory leaks in the program. I'm very new to cocos2d so I don't know how to fix them. Is someone able to help fix these memory leak issues? Please keep in mind I'm a novice. Cheers
I know this may not be what you want, but you should consider converting the project to ARC.
What you should do is add the Cocos2d (and whatever other lib files with it) to a static library. Once this is done, convert your project to ARC using Xcode.
ARC will handle the memory management for you. When ARC is turned on, the compiler will insert the appropriate memory management statements such as retain and release messages. It is best to use ARC as the compiler has a better idea of an object's life cycle and is less prone to human error. This will also save you many potential hours scouring over that sample project.
There is a wonderful tutorial posted here on how to convert Cocos2D projects to ARC http://www.learn-cocos2d.com/2012/04/enabling-arc-cocos2d-project-howto-stepbystep-tutorialguide/
Related
Why does instruments using the leaks tool show so many leaks and then crash after about three leak detection cycles?
That cannot be normal ?
The app I am testing on has one index window with one label in it which, on click opens another window which on click closes itself again.
No big deal yet it seems to have leaks ?
the first detection says 72 new leaks
the second then 8 new leaks ... ?
Does anyone know why this might be ?
Thanks for your help trying to get my head around this
Having developed apps with Titanium for 8 years now this doesn't look anything like it should. Whenever leaks are found by the community it usually is quickly fixed by the dev team. That said, it is very rare leaks are found.
Most memmory leaks are developer generated. For example if you create references to UI elements outside the controller it is in you will have to clean up the reference to that UI element to let garbage collection handle it. Garbage collection cannot trigger if you didn't free the components up.
I will not be able to help you further besides the above as you have not provided any relevant information like SDK version, code that causes it etc. You might've stumbled upon a real memory leak but chances are you're not freeing up resources.
My ipad app is receiving the Level 1 memory warning, so I ran the memory leak Profiler in Xcode 4. Sure enough, when I move one particular slider, it is causing a leak. Move it again, another leak and the leaked bytes escalate.
I am wondering if Xcode 4 provides an easy way to find out specifically which object is getting leaked. I have looked through the method from the slider movement; every time I use alloc/init, i then release it. It would be good know where Xcode is finding the leak since I cannot find it myself.
The Xcode 4 documentation references quite a number of tools. However I wonder if this documentation was not updated from Xcode 3 because those tools are not in the menus mentioned by the docs.
the slider action is:
-(IBAction) sensitivity:(UISlider *)slider{
self.grid.sensitivity=slider.value;
[self.grid setNeedsDisplay];
}
this by itself doesn't suggest a memory leak. However, the "setNeedsDisplay" method, which is quite a lengthy one, does not create a leak when it first runs, so why would it create a leak the second time it runs? All the inits/alloc in that code are released (there are only 3 objects created and released).
I find it useful to run Build/Build and Analyze from the Menu. It doesn't catch everything and it flags a few false alarms, but it's a good (and easy) place to start for automated leak detection.
1.X-Code -> Run -> Run with Performance Tool -> Leaks i am getting a memory leak like Responsible Library :UIKit Responsible Frame:UIKeyBoardInputManagerClassForIn.When i traced it does not point to my code instead it points to some frame works.Is this issue of my code? or any chance of leak from apple's frame work?
In X-Code 3.2 I connected iPhone device and the clicked Build & Analyze the right clicked on product/press cmnd+shift+(A/B) you can see many potential leaks this is static analysis but it is showing potential leaks caused only by my code.Hope this would be helpful for some one.
This issue related to the frameworks.Not in your code.So it can't so in your code.So asper my knowledge no need to worry.
In our company we somehow got code to production which crashed(because Heap got corrupted somehow). Developers developed, after that testers had hands on it and later on it was released natural way(monthly release). Everything was fine till it crashed... We tried to investigate it and found many places where we could get a heap corruption... What could we do to prevent this stuff? Stricken our code reviews(we have it 4/5 all times and only 1 developer doing it without any help from the coder of it)? Change our politics for memory management only through smart pointers or something else? Any advise would be nice!
Switch a managed language (C#, Java, whatever) if you can. If you can't:
Use RAII.
Be very clear about who owns each bit of memory.
Create objects on the stack wherever possible.
Use smart pointers in a consistent way.
Have your code reviewers watch out for the above points.
I'm trying to use boundschecker to analyze a rather complex program. Running the program with boundschecker is almost too slow for it to be of any use since it takes me almost a day to run the program to the point in the code where I suspect the issue exists. Can anyone give me some ideas for how to inspect only certain parts of my software using boundschecker (DevPartner) in Visual Studio 2005?
Thanks in advance for all your help!
I last used BoundsChecker a few years ago, and had the same problems. With large projects, it makes everything run so slowly that it is useless. We ended up ditching it.
But, we still needed some of it's functionality, but like you, not for the whole program. So we had to do it ourselves.
In our case, we mainly used it to try and track down memory leaks. If that's your objective as well, there are other options.
Visual Studio does a pretty good job of telling you about memory leaks when your program exits
It reports leaks in the order that they were created
It will tell you exactly where the leaked memory was created if your source files have this at the top
#ifdef _DEBUG
#undef THIS_FILE
static char THIS_FILE[]=__FILE__;
#define new DEBUG_NEW
#endif
Those help a lot, but it's often not enough. Adding that snippet everywhere isn't always feasible. If you use factory classes, knowing where memory was allocated doesn't help at all. So when all else fails, we take advantage of #2.
Add something like the following:
#define LEAK(str) {char *s = (char*)malloc(100); strcpy(s, str);}
Then, pepper your code with "LEAK("leak1");" or whatever. Run the program, and exit it. Your new leaked strings will display in Visual Studio's leak dump surrounding the existing leaks. Keep adding/moving your LEAK statements and re-running the program to narrow your search until you've pinpointed the exact location. Then fix the leak, remove your debugging leaks, and you're all set!
BoundsChecker tracks all memory allocations and releases in extreme detail. It knows, for instance, that such and such a memory allocation was done from the C runtime heap, which in turn was taken from a Win32 heap, which in turn started life as memory allocated by VirtualAlloc. If the application was instrumented (FinalCheck), it also has detailed information as to which pointers reference the memory.
This is one reason (of many) why the thing is slow.
If BC were to connect to an application late, it would have none of this data built up, and would have either (1) dig it all up at once, or (2) start guessing about things. Neither solution is very practical.
One way to lighten up BoundsChecker is by excluding from instrumentation all but the few modules you are interested in. I know thats not great because if you knew where the leak was you wouldn't need BoundsChecker. What I usually recommend is that you use BC's Active Check mode first with only Memory Tracking available. You miss the API Validations but you could always rerun that seperately. After you run Active Check and you get clues regarding which modules tend to be problematic, only then do you enable instrumentation for the module or modules of interest and their dependencies. We know Final Check is annoyingly slow but as Mistiano correctly states, with Final Check not only does BC keep a graph of all allocated blocks but also all pointers and contexts to them. Therein lies the magic in how Final Check can nail leaks and corruptions at the point of occurance, not just on application shutdown or fault. Shameless plug: I work on the DevPartner team. We are releasing DPS 10.5 on February 4, 2011 with x64 application support in BC. Unlike the relatively ancient and undersold BC64 for Itanium which only provided Active Check, DPS 10.5 provides full Final Check support for x64 applications, both for pure C++ and for native modules running in .NET processes. See microfocus.com under MF Developer for details.