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.
I am new to Xcode and the profiling tool, instruments. I tried to find leaks of my c program. Everything is fine. It shows no leaks, but I don’t understand some terms used in the program. Does mean I still have memory leaks somewhere else in the program?
Applications like the debugger and Instruments may hook into your program after the OS has already started it running. What the message is saying is that it doesn't know how a given piece of memory was allocated because it was allocated before Instruments hooked into your program. So it has no way to track where it came from. It may or may not mean that there are more actual leaks in your program.
I believe that you can start your program from Instruments in most cases, which I think would eliminate the issue. Once you've run it once, you should be able to press the Record button (the red circle) again and it should run the app once more. I think in that situation, it should have access to all of the allocations your app makes.
For what it's worth, I have seen this message before and had it go away during the same run. It was as if it suddenly found the data that explained where the leak came from. I've also seen it happen on one run and be gone on a subsequent run with the same data. In that case it seemed like a timing issue of Instruments and not a legitimate leak.
I've been stressing over this issue for about a week now, trying to pin point the source of a slow but steady Apple Watch app performance degradation. Over the course of about two days, my app's UI would become progressively more sluggish. I've narrowed it down to a complication update code. Even if I strip down the complication update to an absolute bare minimum, this problem still happens, albeit slower than if I update the complication with some actual data. I update the complication every 10 minutes. Once the new data comes, I simply execute
for (CLKComplication *comp in [CLKComplicationServer sharedInstance].activeComplications) {
[[CLKComplicationServer sharedInstance] reloadTimelineForComplication:comp];
}
which in turn calls:
- (void)getCurrentTimelineEntryForComplication:(CLKComplication *)complication withHandler:(void(^)(CLKComplicationTimelineEntry * __nullable))handler {
...
}
This works fine, the new data displays, but when repeated a few dozen times, the UI responsiveness of the main app begins to noticeably degrade, and when it's repeated about a hundred times (which happens in less than a day with 10 minute updates) the UI really slows down significantly.
I have nothing fancy going on with the complication structure - no time travel, just display the current data, and everything is set up for that. To make sure I'm not looking at the wrong place, I've made a test that reloads the timeline every second, and in this test, my getCurrentTimelineEntryForComplication looks like this:
- (void)getCurrentTimelineEntryForComplication:(CLKComplication *)complication withHandler:(void(^)(CLKComplicationTimelineEntry * __nullable))handler {
handler(nil);
}
so there's literally nothing going there, just send back the empty handler. Yet, even in this scenario, after a hundred or so timeline reloads, the main app's UI slows down visibly.
Some other things to note:
If I'm not updating the complication, the app's UI performance never degrades, no matter how many times I open it, or how long I use it, or how many times the data fetching code runs in the background.
When testing this in the simulator, I can't get the performance degradation to happen, but I can consistently see that there's a small, but steady memory leak coming from the complication update (again, this happens no matter how simple update I do inside the getCurrentTimelineEntryForComplication method.
Has anyone else noticed this, and is there any hope to deal with it? Am I doing something wrong? For the time being I make sure only to update the complication if the data has changed, but that just postpones the problem, rather than solving it.
Oct 24 edit
I've done more careful testing on a real watch, and while before for some reason I didn't notice the memory leak associated with this on a real watch, I have now definitely seen it happen. The real device mirrors the issue seen on the simulator completely, just with a different initial amount of memory allocation.
Again, all I do is call reloadTimelineForComplication on a constant loop, and the complication is updated with a single line of text from a cached data object, and the complication controller is otherwise stripped to a bare minimum. When the complication is removed from the watch face, memory leak predictably stops.
My main project is written in ObjectiveC, but I have repeated the test with a test project made in Swift, and there are no differences. Also, the problem persists with the latest XCode 8.1 GM and the watchOS 3.1 beta that's supplied with the simulator that comes with it, as well as running it on a real watch with watchOS3.1 installed.
Jan 24, 2017 edit
Sadly, the issue persists in watchOS 3.1.3, completely unchanged. In the meantime I've contacted Apple's code-level support, sent them sample code, and they've confirmed that the problem exists, and told me to file a bug report. I did file a bug report about two months ago, but up until now it remains unclassified, which I guess means no one looked at it yet.
Jan 31, 2017 edit
Apple has fixed the problem in watchOS3.2 beta 1. I've been testing it both in the simulator and on real watch. Everything's working great, no memory leaks or performance degradation anymore. In the end there were no workarounds for this, until they decided to fix it.
Apple has fixed the problem in watchOS3.2 beta 1. I've been testing it both in the simulator and on real watch. Everything's working great, no memory leaks or performance degradation anymore. In the end there were no workarounds for this, until they decided to fix it.
I noticed that using the native calendar complication everything i do becomes very sluggish. So maybe it's a bug in the new watch OS.
After using the calendar complication for a couple of days it's impossible to use that watch face. Even if I change to another complication and switch back to the calendar one it doesn't "reset" the performance. The only thing that solves is to reboot the watch. (or forget about the calendar and use another complication instead)
Encountering a crash for a iOS9 only. The crash is manifesting in JavaScriptCore though I'm not certain it has anything to do with JavaScriptCore. I'm more inclined to believe this is an issue with memory exhaustion more specifically and possible virtual memory exhaustion. As noted in the screenshot free RAM is exceptionally low so it's definitely not an ideal situation. I don't know enough about iOS internals to entirely what's going on here but wondering if there's others out there who have encountered this type of thing with iOS9. This was not an issue for me on iOS 7.x, iOS 8.x
The issue in this case appears to have been from releasing a JSContext object from a section of code which was not the owner that was setup to run JavaScript. Xcode flagged it in the static analyzer and once the release call was removed all was well. I'm a bit hesitant to say this was for sure the issue since the crash didn't happen 100% of the time but given the testing before/after the change it seems pretty likely.
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/