I'm having trouble finding the cause of an unexpected freeze on iOS because, if pausing the debugger, it doesn't actually pause until unfrozen. Does anyone have any idea on how to track down the actual cause of this before it completely locks up the device?
The simplest answer: don't do anything on the main thread that doesn't have to be on the main thread. For a longer answer, you need to use the Time Profiler probe with Instruments to find the hot spots.
Related
Facing this strange issue where my app crashes after certain period of time. Attached is the screenshot from the Crashlytics as well.
This has occurred in an iPhone 6Plus running iOS 11.4.1.
I'd like to see a full crash log to get more information. With anything related to concurrency, I like to take a look at what all the threads are doing. Sometimes there is a clue in a thread that did not crash.
I do not know what's going on. But I can make an educated guess here that you are seeing heap corruption of some kind. The function "os_unfair_lock_corruption_abort" strongly indicates that the OS's primitive locking mechanism has detected a corrupted data structure, and is killing the processing.
Heap corruption is super-common, and can be extremely difficult to debug. One of the reasons is what you are seeing here is a symptom of the corruption, not the source. The source could be completely unrelated to locking/OperationQueue internals.
My suggestions would be to try out the memory debugging tools at your disposal, and attempt to fix all issues you can find. You might never be able to know which, if any, cause this. But, that's pretty much all you can do.
Check out malloc scribble, guardmalloc, and even NSZombies. All could potentially turn up some heap corruption bugs that are in your code.
I am writing a game in Swift using SpriteKit with Xcode 7.3 on a Mac mini running El Capitan (both updated in last couple of days).
Shortly after I started, my Mac mini started crashing. The error log indicated that a Kernel Panic had occurred likely due to a memory leak & the process was identified as Xcode. Looking at the Activity Monitor, I can see that when this specific app is loaded in Xcode, the memory used by Xcode fairly rapidly increases even though the App is just sitting there doing nothing.
When other apps are loaded & idle, the memory usage stays more or less constant as you would expect. I have Googled for clues for several hours but can find only info. about memory leaks when an App is running & how to detect them with Instruments.
This is a weird one as far as I'm concerned. I do not have any idea how to start to figure out what's causing this other than starting with a fresh project & gradually adding code to see if/where it starts happening again. I would appreciate any ideas other Xcode users may have.
You don't happen to have
skView.showPhysics = true
turned on?
That is know to be causing memory issues exactly as you described.
There are a number of things you can do to start diagnosing this issue. Firstly you say that only one app is doing this. So this would indicate that the problem is an app problem rather than XCode. This is a good thing :-)
Next I would start using the profiler to monitor the memory and allocated objects in the app. try taking snap shots of the memory at regular intervals and look at what has been allocated since the prior snap shot. The profiler can then help you to dig down into the leaking objects and see where they are being retained and released. This might give you the clue you need.
Another thing is try is the profilers leaks monitoring. That also might tell you whats going on inside your app.
Lastly, is there anything in your code that is executing in some sort of loop. Something that animates on the home screen for example. Perhaps that is leaking.
Thanks very much to Drekka & Adrian B for your speedy answers but, as always happens, as soon as I post a question, I stumble across some information that leads to an understanding & (in this case partial) solution. Looking for an answer to a different question, I came across a thread on the Apple Developers Forum where several others are reporting the same issue.
It is related to the use of the SpriteKit Scene Editor. Hence it is app related in that for me it occurred with the only app for which I have ever used the Scene Editor but in reality it is an Xcode bug. What happens is that if the Scene Editor window is open (i.e. the .sks file is selected), even if the scene is blank, Xcode starts to leak memory at a rate of about 1MB/sec. If you close that window, the leakage stops. It happens even if Xcode is minimized. Apparently, it has been reported as a bug. I guess the work around for now is to accept the leakage while you're modifying your scene & then close the editor when you've finished (or do everything in code).
Cheers,
RB
No matter how long I leave the app without touching my cpu doesn't drop below 90% or so. I'm using Parse and I've narrowed it down to Bolts using up the cpu. Is this normal? Is there any way to reduce the usage?
I don't believe I have any endless loops that would cause it.
No, that is not normal, and will drain your users’ batteries. An app that does that is definitely not releasable.
It’s impossible to know how to reduce the usage without much more diagnostic info, but it’s well worth the time to track it down.
A starting point could be to pause the offending thread in the debugger while the CPU is pegged, and see what the code is doing. If it’s inside Parse, as your profile screenshot suggests, that won’t tell you much — but sometimes examining the pegged code in the debugger as it executes reveals info that Instruments does not.
I have an app that I am building for iOS 7 only and running on an iPhone 5S. The app sometimes in normal use just freezes up and won't recognize any touch interactions happen and it requires the app to be force quit. I have noticed it doing many different tasks and in different views. I have had this problem while debugging and the RAM usage is at about 65 Mb which I think is pretty good, cpu usage is in the single digits and the debugger doesn't register a crash. Where can I go from here in terms of debugging and trying to fix this pretty serious problem?
To put my comment as an answer, usually when your application freezes, it means either the CPU is doing some heavy lifting or your have a deadlock somewhere. As you mentioned that it was the CPU usage was low, my first guess was a deadlock.
Thanks to Leo Natan for suggesting that it was deadlocks, because it was. There was a specific instance where I was saving and fetching from the background thread and there was an easy solution that made it possible for me to stop fetching on the background thread.
For me, it was an endless while loop. Found it out by pausing the process and checking out the stack trace.
I'm writing a game using Corona for a game design class and though I'm still learning, I've got most of the basics down. Right now, I have a situation where the program slows down after about two minutes or so of playing, and I'm not entirely sure why. I've already implemented code to remove all bodies which have served their purpose and I even have it set up to print a notification when each one is removed.
http://www.mediafire.com/?5fz7ru0c6euwq1k
This is the download link. Any help is greatly appreciated. Thanks!
First off, have you checked the memory usage? If the problem gradually slows down that certainly sounds like a memory leak, but you need to check the memory usage to be sure. Print out memory usage to the console like so:
print("mem "..collectgarbage("count"))
Put that in an enterFrame listener so that you can watch the memory usage continuously while your app is running.
Now once you are seeing the memory consumed by your app, the most crucial step in any sort of debugging is isolating the problem. That is, zero in on the spot in the code that causes the problem. For some problems you can rely on techniques like printing debug messages to the console, but for a memory leak your best bet is often to selectively comment out sections of the code to see what affect that has on memory.
For example, first comment out the event listeners on one screen and then check the memory usage. If the leak is gone, then you know the problem was something to do with those event listeners. If the leak is unaffected, then restore those event listeners and comment out the next possible cause of a memory leak. rinse and repeat
Once you know the exact section of code that is causing the leak, you will probably be able to see what you need to fix. If not, ask about that specific code.