This appears to be an iOS 8 problem only. I haven't seen it anywhere else, and it only happens on iOS 8. This is not local to my app, as it seems to affect nearly every app on my phone, including ones that haven't been updated to iOS 8. The crash is a EXC_CRASH (SIGABRT) which seems to trigger on random threads. The back trace is of no help of course because I can't re-symbolicate the crash reports from different builds and applications. So I decided to run my app in Xcode and recreate events that lead up to this crash. Essentially I just run my app so it's loaded, press the home button to switch to another app, do some stuff on my phone and return back to my app several seconds later. When I did get it to crash, and returned back to my app, instead of getting a SIGABRT and getting a stack trace, instead I get a SIGKILL and a (lldb) message in the console. This is strange because it does not crash while in the background but instead when returning to the foreground so any background process are uninterrupted. And because there is no stack trace, I have no idea why this is happening. To my knowledge, a SIGKILL is only given by Xcode when I press the stop button and when an app uses too much memory. Neither events occured. Has any one experienced this and/or solved it?
Related
Since moving to Xcode 9 I observe a strange behaviour while resuming from a breakpoint on Simulator.
My app uses multiple threads significantly, and some breakpoints are set in the code on different threads.
Once the app stops on a breakpoint and then is resumed (repeated a couple of times on different breakpoints)
it freezes eventually forever, which looks like a deadlock on a main thread:
UI is unresponsive
(however some UI animations are played) and the callstack shows __ulock_wait on the main thread.
In the same time
other background threads shows various actions e.g. on logging mechanism (CocoaLumberjack),
downloading pictures (Alamofire), etc.
This is not happening while testing on the same breakpoints on a device connected to the Xcode or on previous version of Xcode.
I've also tested the behaviour on one of many PODs' demo app used in the app with the same result.
Described behaviour brings debugging experience to annoying level and even breaks possibility to debug some part of the code completely.
Could anyone confirm a similar, unwanted behaviour?
I have an app that work in background because i add App provides Voice over IP services to info.plist
when my app go to background and touch twice on home button and exist app from background , it crashed
how can i check why happen this problem?does any event call from AppDelegate when do it?
In Navigator -> Breakpoint Navigator: Add Exception Breakpoint
Now simulate your crash, your application will stuck on the line your app got stuck, check thread and objects allocations.
I guess this may help you out a little bit :)
I am new to iOS development and i am facing an issue.
Putting breakpoints in my app before running the app in simulator is causing unexpected behavior.
If I put breakpoints in my app then I am not able to type in to text controls or click buttons i.e. it makes entire view read only.
If I disable the breakpoints, my app runs fine.
Any pointers to this issue will be really helpful.
Thanks
You are hitting a breakpoint which pauses execution of the main (UI) thread. Your application will not be able to process touch events when it is paused. Click the play button in Xcode to resume execution.
I was inspecting my crash log and noticed several apps appear to have been jettisoned. But looking at the multitasking bar, they are still there. Is there another way I can confirm that inactive apps are actually being jettisoned before my app crashes? Can this be seen in any of the tools?
Up until now, I assumed my app was being closed without the inactive apps being jettisoned. Now I'm unsure.
Update
I have, on several occasions, had my crashing app stop crashing after I removed everything from the multitasking bar. I didn't check the crash log in those cases, and I'll have to do that in the future. But it's hard to imagine that that was just a coincidence.
The bar is simply a launch history. It doesnt represent the current state of your device memory except by coincidence.....
I used instruments to see what the memory usage was while my app was running. I can see that real memory in the Memory Monitor reports the amount of real memory being used by each app.
Seeing that several inactive apps were showing memory use, I confirmed that they were in the multitasking bar. I was able to manually delete each one from the bar and saw an immediate response in memory usage. Each deleted app disappeared from the memory usage list.
This answers my question -- Instruments can show how much memory is used by apps that show up in the multitasking bar.
Apparently, the multitasking bar is showing applications that are currently taking real memory. It is not just a launch history.
That being said, I don't understand why Jetsam does not release these apps before killing my running app. I'll post that question later as a new one.
This is very difficult issue, since it doesn't occur every time.
When an app is just launched, returning from background, it is fine without any freezing.
After some time being in background, when I re-activate it, the whole UI is frozen for while, even the activity indicator is not animating. As time goes on, this freezing gets longer and finally causes the app to be terminated by iOS for not resuming in time.
I would like to learn what are the generic causes of an app to be unresponsive, especially if the app is supporting background running feature and re-activating after a period of being in background.
It looks like I have missed some fundamental techniques that should be respected to avoid freezing problems.
UPDATE: I am suspicious if saving UIImage into Core Data object can be the main reason. At launch, it's not visible, however, as time passes, numerous saveManagedObjectContext are performed while UIImage is still referenced.
Maybe I should have listened to the instruction not to save any image in Core Data?
check for your crash log if you are getting this
Exception Codes: 0x8badf00d
then its most probably your application is taking much time either in launch or while moving in background or terminate, actually app take much time in launch/shut iOS suspend it and our app freeze, there is no such time define in documents but as i experienced it should not be more then 4-5 seconds. check your app delegate applicationDidFinishLaunch or multitasking delegates there is some code which is taking time in completion. For more info lokk at these
http://developer.apple.com/library/ios/#technotes/tn2151/_index.html
http://en.wikipedia.org/wiki/Hexspeak