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.
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.
Wondering if others have experienced this as well in Xcode: my app seems to have no crash issues when running normally OR in Instruments (Allocations) but if I run it from the debugger on my phone it will eventually (after ~10 rounds in my game) crash due to memory error (no other information provided).
One thought: I have malloc stack logging enabled and was curious if this might lead to memory accumulation that is unrealistic otherwise. At this point it seems like there's no real-world / non-debugger issue based on my testing, but as a relative rookie at memory management I am uncomfortable saying Xcode is giving me a false positive. Any ideas?
I just upgraded from XCode 9.2 to XCode 9.3.
Since then my playground is very unresponsive/slow, animations play at unexpected times and UIKit elements are not properly layouted anymore.
Are there any known issues and/or fixes that I can apply?
Had same issue and there was no way around it. People filed bugs as far back as April 8th.
Best solution is to download Xcode 9.4 Beta from Apple Developer Page.
This worked for me and CPU usage is low and Xcode doesn't crash on playgrounds anymore.
Playgrounds have been buggy all along but 9.3 takes it to another level. Have you noticed a “diagnosticd” process taking up much of the cpu while running playgrounds? I suspect that this may be in part responsible for the lack of performance. Not much to do until Apple gets their act together (if ever)
Xcode 9.3.1 has just been released (10 May 2018) and is supposed to fix 'an issue that caused Xcode to slow down when editing a playground'.
Kill "homed"
My experience is that homed is going nuts, hogging the CPU.
Without quitting the Playground app, you can go into Activity Monitor (Applications > Utitlities > Activity Monitor) and sort by %CPU, you might see Process Name homed taking a large CPU load. Double clicking on homed and selecting Quit does not seem to harm the workings of the playground.
If you still encounter problems, you could close the Playground app, and use the same process to force quit com.apple.CoreSimulator.CoreSimulatorService, although doing that requires a lengthy process when you restart your Playground.
I am looking for ways in which memory leaks could be detected at the time of development something like a dump of leaks on console.
I am not talking about using leaks, shark, instruments. We use them after development. Sometimes finding the leaks after all development is real pain.
Thank you
When you build your app, you should always also perform "Analyze". It's available just below the build command in the menu if you use Xcode 4. This will catch almost all Objective-C leaks, and shows how an object is leaked as a curvy lines connecting the program texts.
Eliminate all warnings by the analyzer. That will solve 90% of the leak before even running your app.
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.