iOS 4.1 CLLocationManager delegate stops getting called - RunLoop blocked? - ios

OK, this one has me stumped. I use the CLLocationManager services (iOS 4.1) in my application. The delegate gets called as it should at first. Then (some arbitrary time interval later), the delegate stops getting called. It almost looks like that RunLoop is getting blocked somewhere.
I have even reduced the callback to one NSLog statement, and I see the same behavior. Do we have any gdb experts out there who could give me some hints how to look at all of the running threads, and determine which one is blocked where ?
As a test, I have also put a button on the GUI which stops are starts both heading and location updates - this seems to unjam things for a while.
Other info:
This is on an iPhone 4, app has been run through Instruments (leaks and allocations), everything looks good there. Any hints would be appreciated, I am currently out of ideas...

Mea culpa... I had errant logic which was firing a timer, shutting off the service. One again, caution is called for when making supposed "small" changes. My apologies if anyone wasted effort on this one....

Related

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!

How to debug syscall_thread_switch in iOS 8.3?

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.

VM:Allocation causes app to crash

My app uses NSTimer variable which uses NSNotificationCenter.postNotificationName to post notification to UIViewController class every seconds.
The issue is the app crashes once in a while with no stacktrace which mean it is a memory issue.
From Instruments, it happens because a 1.78MB increase in VM:Allocation. The allocation just happens randomly.
Here is right after I start the timer:
Here is when I start the timer for a few minutes
So,
I don't see stacktrace or anything. How do I go about debugging
this?
The app use only 7.3MB and is in the foreground, why does it get
kill?? :(
I just leave the timer running, the method only updating existing
variables, what trigger this VM:Allocation???
I use Swift, if that matters
Thanks,
Turn out the problem is in the for loop. I had a big for loop that do a lot of assignment, calling API, etc, every time the NSTimer function is called so sometime when the number of iterations are a little bit too high the VM Allocation kicks in.
The answer I believe is to use autoreleasepool {} inside the for loop. No crash has happens ever since.
Watching these WWDC2013 video helps a bit in term of ideas but not directly.
Improving Your App with Instruments
Intermediate Swift

CLLocationManager weird behaviour on IOS?

Sometimes CLLocationManager doesn't give call back to my app. It neither call didUpdateLocation or failure delegate method. I am unable to understand why such behaviour of LocationManager. This thing happen rarely but still happen and break the functionality of location. If anybody can help me regarding this that will be highly appreciated.
I remember the location manager having some kind of issue when an application goes into the background. It could stop updating for 5 to 20 minutes. But after that it would return to better, if not quite normal, behavior.

removeWithCompletionHandler causes logging out of Game Center

I am using GKTurnBasedMatch's removeWithCompletionHandler to programmatically remove old (finished, i.e., with status = GKTurnBasedMatchStatusEnded) turn-based matches from Game Center when needed (to avoid extra loading burden, I want to keep the amount of finished matches to a minimum).
I am getting no error and the match is correctly removed.
However, most times I do this, my user gets kicked out of Game Center, so the local player is no longer authenticated. This happens on iOS7, with both iPhone and iPad.
Did anyone experience this? Is there any way around it?
NB: I might as well not remove matches from GC, as I use internal business logic to determine which matches should be listed to the user and show, say, only the 10 (unfinished) most recent ones. However, I am afraid that hundreds of games might be kept in GC and that this might slow down interactions with GC when I have to list ongoing matches.
If you're calling removeWithCompletionHandler inside of a completion handler for another Game Center API call then you might be experiencing the very same issue that's been plaguing me for a while. The solution I tried today involves simply delaying the call to removeWithCompletionHandler for a few seconds, like so:
[match performSelector:#selector(removeWithCompletionHandler:) withObject:^(NSError *error) { /* callback code here */ } afterDelay:3.0];
For me, this worked great but meant I had to rework a few things in relation to displaying active games... so be wary of that if this solution works for you. Also, it's worth noting that the 3 second delay is an arbitrary value I picked and it worked for me.
In my case, I was calling removeWithCompletionHandler inside the completion handler block for the various quit methods on GKTurnBasedMatch.
I imagine there is some issue on Game Center's end where the two requests cannot be made so close together without resulting in such woe. This is evidenced by the fact that the issue did not ever occur for me when I slowly stepped through the calls to Game Center.
EDIT
Here's some cool news; seems like they've fixed the bug in iOS 8. I built an app which demonstrates the bug for bug-reporting purposes (originally for iOS 7). I've tested that same app running in iOS 8 and it seems that the bug has been squashed.
Finally.
IMO, you should consider adding the removeWithCompletionHandler call in now.

Resources