I am seeing main thread freezing for a few seconds in my app only on iOS 8 (not on previous iOS versions).
I am using #synchronised (self) at a number of places and also using RemoteIO setup. My question is how do I debug where exactly is the main thread blocking and get additional information, such as what it is doing at that time ?
I am using Xcode 6 so please tell me the best way to debug.
EDIT: Here is the output from Pause.
As a first step to understand what's happening I would suggest to simply press Pause in debugger while you're having a freeze. It will show you which thread is doing what at that point.
You will either see a task that is still executing, or msg_trap row indicating that there's a lock somewhere.
Post here what you found out.
Related
I have sometimes app freezing I do not know what is the source of problem.
It happens rarely but happens. I consider how to track such issue
I have crashlytics from firebase but there is no errors as freezing is I suppose something with threads maybe some deadlocks or infinite loops.
Is there way to track such things?
What maybe reasons of app freezing and being inactive (it is SwiftUI app) ?
Are there possibilities to track/profile apps installed on devices (not connected via Xcode) and send informations such that are available in Instrument to something like firebase console or other 3rd party tools.
Update
I think I do not indicated important fact.
It freezes UI definitely not for a few seconds but app need do be killed and restarted again.
There might be some heavy process that locks your main thread, so it freezes your UI.
You track the problems, performance, leaks and more using Instruments.
There are sample topics:
Instruments Tutorial with Swift: Getting Started
How to find and fix slow code using Instruments
And WWDC videos like
Using Time Profiler in Instruments
Creating Custom Instruments
I have experienced some of these weird behaviours before. And mostly the reason behind it was a task that is blocking the main thread making it unresponsive. Pause the app and check the stack trace. Also make sure all your UI operations are done on the main thread. Hope this helps!
If I write accidentally UI updating code on a background thread after fetching data from network req. So Will my application get crash?
From apple docs:
Updating UI on a thread other than the main thread is a common mistake that can result in missed UI updates, visual defects, data corruptions, and crashes. source
So it can crash, but it can also not crash. It might update the UI or it might not. It might crash immediately when the code is called; it might crash in the next runloop, or it might crash minutes later. It might cause weird UI that make you say WTF. In short, its behavior is undefined. Which makes can make it a really hard bug to track down and fix.
If you are asking what is the exact behavior to expect when doing this. The answer is: in a debug environment you should expect the Main Thread Checker to catch it and cause a crash with a good crash report. If it is a production build you can expect some crashes that look like this: Application crashes very rarely with UI update on secondary thread, but they might look different. If you have a small user base you might not see any crashes, but still have a very buggy app.
Straight Answer : Your Application Won't crash.
UI Update must be done in Main thread
Apple Documentation:
DispatchQueue manages the execution of work items. Each work item
submitted to a queue is processed on a pool of threads managed by the
system.
So, use
DispatchQueue.main.async {
//your UI code
}
Why do you want to update UI in the background thread ? it's a bad practice.
You'll get something like this:
I have an app where I read data from input stream and visualize it to user. When I set up input stream, I set it up in background run loop, open it and then run a background loop. But sometimes my app breaks unexpectedly. I can't repeat this crash so I don't even know where to start to fix it.
The crash I get looks like this:
And the method where it crashes looks like this:
It says that it is Enqueued from background queue (Thread 3). And Thread 3 looks like that:
What could be the reason of this? Where should I start to fix it?
And the strange thing is that in Thread 17, where it crashes variable bg_queue is nil, and anyway it passes the if condition where i do
if (bg_queue != nil)
But in Thread 3 it is not nil:
Thread 17
Thread 3
It seems, you create a run loop from a secondary thread managed by GCD. You should not obtain a run loop from a thread that is managed by GCD!
Create your own dedicated thread or use the main thread to obtain a run loop.
If you create a second runloop, you are more courageous than I am. I would never dare doing that, because I would be just sure that it leads to problems that are too hard for me to fix. As you are finding out.
If you are sure that you are a much more clever developer than I am, then sorry, you're on your own. If you are not sure, then DON'T DO THAT! Stay away from secondary run loops!
Since moving to iOS 8.3, I'm encountering this error where the main thread will get stuck in this call. A few other threads are also stuck in that call. There is none of my code in any thread that leads to this call, so I'm stumped as to why this is happening. It happens randomly, sometimes, when tapping a button bar item, sometimes while redrawing charts (using ShinobiCharts), etc.
Here is the stack trace from Xcode:
Anybody has any clue as to why this is happening and how to fix it? It's very annoying because when I get stuck there, I have to relaunch the app. Note that this is happening in the simulator so far. I'm in the early stage of developing this app and spend most of my time in the simulator. I haven't seen the error happening yet on a real device but, again, I haven't run the app that often on the device.
Knock on wood, but I think I figured it out (at least in my instance).
What led to the solution was a search for syscall_thread_switch, which led me to this answer here:
https://stackoverflow.com/a/30333203/978509
Which, if you look at the backtrace I linked (https://gist.github.com/Shalmezad/65ff89d20aa7e0a9d094), every syscall_thread_switch is preceded by OSSpinLockLockSlow, which the answer notes looks like Livelock, but due to the low CPU usage, is more evident of a deadlock.
Going through my code, I found that for every background task, I created a new dispatch_queue_t each time. I since redid how that works to use the same queue, which seems to have fixed the issue.
Without further information from nemesis (mainly some code snippets showing how he's setting up background tasks), I cannot answer their specific question, however this should point people in the right direction for fixing the issue.
I have a game that I'm getting ready to submit. I've tested it a lot and it seems to be solid -- no crashes and no unexpected behavior. I am not forcing anything to run on the main thread (except for one place where I followed a sample in a book) and now I'm concerned that under some circumstance, on somebody else's device, the game will not work right or crash because I'm not doing something on the main thread that should be on the main thread. But I don't understand what needs to be run on the main thread. I googled for a checklist or summary of what methods need run on the main thread and didn't find anything useful. Is this something I need to worry about? The app is for iOS 5.1 and up and it uses in-app purchases and Game Center. I use the cocos2d framework and also a lot of UIKit stuff.
most methods running on the main thread are fine,
especially the UI,
you want to use the back thread for processes that can take long, like http requests, database or data sorting, or any other process that can pause the user experience while is processing.
if you load lots of objects you can produce a memory warning that can result in a crash,
so you can release non needed objects when you get a memory release.
good luck