I am working on a project which includes following functionalities.
Location fetch and send to server in every 60 seconds.
Audio/Video Calls.
The background modes which are set for the project are mentioned as under
iOS: 14.1
Xcode: 12.1
Swift: 4
Problem:
Whenever I put the app in background it fetches location or call for sometime then I get following error in logs. Whenever I put the app in background when audio call is going on then audio works for some time and after few seconds following error arise.
Message from debugger: Terminated due to signal 9.
How ever all things work fine when the application is in foreground. Application fetches location and call works.
Kindly suggest what additional I have to do or anything wrong am I doing.
The comment thread on your question suggested that the termination is due to excessive background CPU usage.
Based on your last comment, it sounds like you don't know where to start with Instruments (I've been there) as another commenter recommended, so I'll give some basic info on how to get started with CPU profiling in instruments, and then you can seek out more detailed tutorials online (this WWDC video from Apple is as good a place to start as any: https://developer.apple.com/videos/play/wwdc2019/411/#:~:text=Instruments%20is%20a%20powerful%20performance,optimize%20their%20behavior%20and%20performance )
The following assumes using Xcode 12.1 and its corresponding Instruments version 12.1, but most recent versions should be fairly similar (maybe a button is slightly differently placed, etc. in older versions):
Open your app project in Xcode, and run it on a real device (simulators will give you information about your mac's CPU usage and will be very different to a real device).
Go to the Debug navigator in the left sidebar (Cmd+7), select CPU in the sidebar, then click the Profile in Instruments button on the top right.
Select 'Profile Current Session' if asked.
Instruments should launch and start recording automatically.
Reproduce the issue on your device.
Now to understand what's being shown in Instruments:
The top pane (the moving chart) shows your CPU usage over time.
The bottom pane shows the call tree of processes that have run.
There's a lot of info there, so you want to look at the Filter and configuration bar at the very bottom of the window, and select all the options in the Call Tree menu in the first instance. It looks like this:
Here's a short explanation of each of those options:
Separate by Thread: Shows the processes by thread to help diagnose overworked threads
Invert Call Tree: Reverses the stack to show the bottom portion first which is likely more useful for troubleshooting
Hide System Libraries: Removes system library processes so there's less noise & you can focus only on your app's code
Flatten Recursion: Combines recursive calls into one single entry
Top Functions: Combines the time the called function used, plus the time spent by functions called from that function. This can help you find your most expensive methods in terms of CPU usage.
Now you've got a filtered list of expensive CPU methods for your app only, and selecting a row gives you more information in the Extended Details pane to the right of the call tree view. This can show you exactly which method in which file of your code was running and even take you to it in Xcode (with a few button clicks).
Hopefully that should be enough to get you started, recognise some potential problem areas in your code that may be the cause of your app being terminated.
Related
I'm trying to monitor performance of my app;
When cpu usage overloads, I dump the stack trace of the suspicious thread and main thread as string by two libs:
https://github.com/bestswifter/BSBacktraceLogger
https://github.com/plausiblelabs/plcrashreporter
Following are the stack trace of one thread that I record, but it cannot help me analyze and locate where the performance issue is.
Am I doing wrong or how can I analyze the stack trace of a thread?
Ohkay ! I somewhat got your problem. What is your app about,? I mean is it a Game or something.? With this very info, I'll give you few workarounds,
I would suggest you to thoroughly study the code and de-initialize all the resources which are not being used.
Check for how many static properties and global variables/properties you’re using and ask yourself are they even required ?
Also I would again suggest you to monitor your app with Instruments look very precisely when the memory bar is going high and when low [e.g. by opening what ViewController it eats up a lot, by closing what ViewController the memory bar goes down, is your app dependent on GPS coz in big applications like uber they do not update locations on didUpdateLocations rather they use other methods, like singletons / Timer / heartbeats etc,]
Plus if you wanna avoid all this manual work, go for NewRelic
A small tutorial for that : link
Post again for more, Would be happy to help. =)
Here are some links : by using and combining them with firebase you'll be able to see events and logs as well,
here's 1st -> watchdog
here's the 2nd 1 -> Prints the filename, function name, line number and textual..etc..
Now combine any of that with firebase and it'll send the logs to you directly.
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.
We had to use CoFreeUnusedLibrariesEx for fixing a bug with heap not being cleared after using a MSXML library
Refer this link:
http://blogs.msdn.com/b/marcelolr/archive/2008/11/13/msxml-heaps-not-being-released.aspx
But this caused another issue with TTimers which takes while to show up and disappears when Delphi app is bounced and again shows after a while.
This app uses TTimers to schedule it's job like running a XML transform .
Here is the issue:
When TTimer.Enable is called it throws an error not enough Timer available.
I know this is a masked error and I would have to figure out how to get to the actual error.
This is a single threaded application with only one timer.
Here are the links I looked into
Most Common reason seems to be invalid windows handle
https://groups.google.com/forum/#!topic/borland.public.delphi.winapi/UrIskaFZggU
There are other threads that suggested that OS ran out of resources for TIMERS I'm not sure if that is relevant to me.
I'm Just trying to understand what is Interaction between CoFreeUnusedLibrariesEx and TTimers that it gradually some how robs it of resources and makes us bounce the app to get it working.
How do I go about solving this issue , I'm looking for some directions?
CoFreeUnusedLibrariesEx should not affect TTimers. But if loading and unloading a (buggy) dll leaks any user objects (this includes timers, window handles, ...) then I could imagine that you run out of user objects.
Use Windows Task Manager and configure it so it will show the "USER Objects" in the "Processes" tab. Then compare the number of user objects when you call CoFreeUnusedLibrariesEx and when you don't call CoFreeUnusedLibrariesEx.
As nice as debuggers have gotten these days, sometimes the best way of finding out what is going on in an app is still ye olde NSLog. Doing this is easy when you're tethered to your computer; Xcode helpfully pops up the Log Viewer panel and there you go. Not so easy to do when you're away from your desk, as you sometimes have to be when testing an app (for example, when you are testing CoreLocation functionality). Sure you can pop open Xcode and check the Console section of the Device Organizer as soon as you get back from a testing run, but then you have to wait, and by the time you can get back to view the logs you forgot what was going wrong with your app; also odds are that by the time you are able to do this, the log messages you are looking for have scrolled off into oblivion.
Is there any way of checking the console logs on the device itself? I'm guessing the answer is "no, unless you jailbreak" (IIRC there are at least one or two terminal apps in jailbreak-land that I could use to do this sort of thing). Unfortunately jailbreaking is not an option for me.
Alternatively, is there some sort of Objective-C framework or library or whatnot that handles log collection and on-device displaying? Ideally this would come in the form of a drop-in replacement for NSLog, whereby I could simply do a search-and-replace and change all occurrences of NSLog to SomeFancyPantsLoggingTool or whatever and be done with it.
A good example of the kind of functionality I am looking for can be found in the podcast client Downcast. If you tap the "More" tab, then tap on the version number string at the bottom of the screen, a new view slides up that contains a scrollable view of accumulated log messages. It even has an easy way of mailing said logs to a support e-mail address.
Take a look at LibComponentLogging which you can configure to output logging at different levels and to different destinations.
There is a file for the SysLog. You can simply open it and read from it. The file is at /var/log/syslog. If the file does not exist there are instructions on how to set it up here.
I have a question that I can't really answer, so I wonder if someone may shed some light here.
Basically I am interested in knowing what is going on in iOS before and while I run an app...but from the OS perspective.
I've seen a lot of posts regarding what happens when the user tap on an app in the main screen, but I am interested in knowing basically what happens behind the scenes, before that the app takes control and main runs the singleton for UIApplication. And also once that the app is running, is the whole OS blocked in the main run loop of the app or something else is going on?
In particular, I would like to understand who creates the process where UIApplication will run (so the whole app will run inside that process, I assume).
Also would like to know what is the OS doing when for example, I open a connection in an app...since I see that a new thread is created (looking at a crash report I see a bunch of threads running, not just the main one), but I don't get where and who creates them (UIApplication itself?, where they running already before launching the app?).
Hope that the question is clear; I've search all over to find info but all that I get is that when you tap an app, main() runs and calls UIApplication,which takes control, deal with the delegate and views and so on...but what is going in the OS is a mystery.
Is there any resource related to the iOS part? Thanks!
The operating system of the iPhone works really similar to any other modern operating system. There is a kernel which provides low level functions, an API that provides high level functions (either to applications either to the OS itself) and so on.
There are a lot of processes always alive in the OS itself, just think about the fact that the device is able to receive notifications, receive calls, manage connections and whatever it needs to run.
When you launch an application the only thing that changes is that a process is launched and the control of it is given to the application.
And also once that the app is running, is the whole OS blocked in the main run loop of the app or something else is going on?
The whole OS is not blocked, the process launched is just scheduled together with many other processes that constantly run. This is achieved by multi-tasking.
In particular, I would like to understand who creates the process where UIApplication will run (so the whole app will run inside that process, I assume).
The process is created by the OS itself, which istantiates a new process structure to manage the just launched application and schedule it (with a high priority since it will run in foreground).
(UIApplication itself?, where they running already before launching the app?).
Threads are similar to processes in the sense that they have their code and they actually do something but a thread is lightweight because many thread can be managed by just one process. This mean that your application (or an API call) can create a thread which will run together with the main thread of your application and manage their operations but all these thread will share the same CPU allocation time and the same memory space and whatever. Actually Cocoa hides many of the details from a developer point of view, so that you don't care exactly about which threads are automatically started by the application because you don't need to: they are used to dispatch messages between objects, to manage asyncronous events and whatever.
But this is just the tip of the iceberg, before understanding how iOS works you should learn how a lower level infrastructure works, eg BSD Unix which is actually one of the ancestors of Darwin, which is the kernel on which iOS is operating. After understanding how it works you will undersand also how the infrastructure over it works (which is iOS + its API).