How to debug syscall_thread_switch in iOS 8.3? - ios

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.

Related

Xcode/iOS App freezing, how to track such errors

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!

Users experiencing crash related to Firestore Pod's internal grpc::ClientAsyncReaderWriter<grpc::ByteBuffer, grpc::ByteBuffer>::Finish

Users are getting this crash in testing. My first guess was that it's memory-related but I don't have much more to go off of than that. Looking deeper into the code, I thought this might have been a Main Thread issue but it looks like listeners are removed on a background thread, so I'm skeptical that that's the reason.
I thought that removing any active listeners when the app backgrounds and re-adding them when the app foregrounds might negate this crash but it doesn't seem to have helped.
Any advice on how to fix this crash? Thanks!
Edit: I left the simulator open for long enough and I got this, which is probably the same crash.
Edit 2: Profiling with the Leaks Instrument didn't turn up anything related to Firestore. It only had 7 small leaks related to Foundation and UIKit after the app closed
Looks like this was introduced in 0.15.0 – https://github.com/firebase/firebase-ios-sdk/issues/2138

how to know that where exactly app getting stuck in xcode?

My app gets stuck for a specific operation and that operation is too big having so many method calls and services requests, so i cannot put breakpoints on each method and debug, is there any other way i can get to know where exactly my app is stucked in xcode?
The operation wasn't too big to write the code, so it isn't too big to add breakpoints, logging statements, assertions and so on.
The only other way that works sometimes is taking a long shower in the morning, not thinking about work at all, and suddenly the realisation what you did wrong jumps to your mind. It has worked for me sometimes, but the first method is more reliable.
If you have reason to believe that the most time is spent in one operation, just let it run with the debugger attached and then press the pause button and see where you are...
A somewhat niftier approach would be to start with Instruments (i.e. the Time Profiler). It's easy to use and should be the first weapon of your choice for performance issues.
You can set a conditional break point in Xcode to debug a specific condition, for more detail go through Jeffrey Sambells blog!

iOS: signal SIGTRAP with no breakpoints?

I'm working on an iPad application and a recent change I made is causing the app to die with "signal SIGTRAP". The stack trace doesn't help and I can't pinpoint what part of the code is causing this to happen (but I do know which function it starts from).
Without going into details about the application I was wondering if there are some general tips for debugging this kind of thing (SIGTRAP)?
I've managed to narrow down which function call causes this to happen. The weird thing is that if I break and step into the function then it works fine. But if I let it run without a breakpoint then it crashes.
The function calls a bunch of other things which also involve asynchronous network connections. I put logs all over my code and all my logs print fine, so it seems something "under the hood" is causing this failure. I'm also using a 3rd party framework which may be causing this issue?
Is this even a code-related issue? I read somewhere that SIGTRAP is a debugger thing.
What causes this kind of crash and where should I be focusing my efforts to fix it?
Any help you can provide is greatly appreciated.
Thanks!

NSPlaceHolderString leaking, Instruments isn't telling me where?

I've recently finished my first iPhone app that I'm actually planning to submit, and I'm trying to clear out all the leaks. However there's one that I just can't seem to track down, and Instruments isn't really helping me either. Essentially, I've made something like a to-do list app (that's not really important though) and every time a user deletes a to-do, instruments registers a leak.
Instead of me trying to explain further, here's a screenshot:
http://dl.dropbox.com/u/1426380/Screen%20shot%202011-02-09%20at%2021.51.09.png
So instead of telling my exactly where the leak is coming from (like with previous leaks I've fixed), iInstruments just points to somewhere in the foundation library. It's only leaking 16B each time, so it's not really an issue of crashing, but I'm simply interested as to what is causing this.
I would love to post some code, but since I have no idea where the leak is originating, I have no idea what to post. If someone had an insight on what might be causing this, I'd be happy to oblige.
Thanks.
EDIT:
Here's another screenshot as requested by #Moshe. I'm new to instruments so I didn't even realise that the right panel existed until now!
http://dl.dropbox.com/u/1426380/Screen%20shot%202011-02-10%20at%2007.55.58.png
I suggest running "Build and Analyze". (In the Build Menu, or ⌘ + shift + A).
If that returns nothing, it could be that an Apple framework is leaking. If that is the case, there is nothing you can do.

Resources