When I use the 5.0 simulator I don't get any error at all.
When I use the 4.3 simulator I get the following message when I stop the execution of the app in Xcode using the the stop button.
Basically, I am navigating through my program and I launch a view with a uiwebview the following comes up in the console:
Attaching to process 13343.
[Switching to process 13343 thread 0x2103]
I continue using the App and I only when I stop the execution do I get the following error message:
Thread one program received: SIGKILL
I think the issue is that another thread was opened when it requires user interaction from the uiwebview. And, then when I send the kill message the first thread receives the sigkill and complains with the error.
If I load the same view without the uiwebview, I don't get the error message at all.
And, when I use the 5.0 simulator I don't get this error message at all when loading the uiwebview.
I have seen similar behaviour with the uitextview.
Is this something I should be worried about? It doesn't seem to be a problem when running on the actual hardware.
Is there a way I can switch back to thread one after I push the other view and am done with the uiwebview?
SIGKILL is sent by the OS to any app to tell it to quit what it's running and remove its processes. SIGKILL is not an error on your part, and is not a simulator bug, it's what happens when you press the home button and kill the app in the multitasking drawer, or press the stop button on Xcode. So to reiterate, do not think its your fault, it's just the simulator freaking out sometimes. (Like once, I kept a device in debug mode and restarted my device and got like 300 lines of binary in the log, that was creepy!)
PS (though I HIGHLY doubt you are having this problem: SIGKILL may also be sent in cases where your app is using WAY too much memory, which would cause an exception or an EXC_BAD_ACCESS depending on how you managed to do it, but again, highly unlikely).
Related
There is a crash happen when coming back from background through app icon.
However I cannot see any detail info in console log. There is a signal to terminate, but we cannot find signal number.
<FBApplicationProcess: 0x117bcb930; Maixxxx; pid: 1762> exited abnormally via signal.
Process exited: <FBApplicationProcess: 0x117bcb930; Maixxx; pid: -1> -> <FBApplicationProcessExitContext: 0x17103f820; exitReason: signal; terminationReason: (none)>
The procedures to reproduce my crash is as follow:
Start app through click on app icon.
Use the app as normal user.
Press home to put it in background.
Wait for some minutes.
Click the app icon on springboard screen in order to use it again.
The app crash&exit.
Since the crash only happen when coming back from background, and required to enter background for some minutes, I cannot run in debug mode with lldb attached.
I didn't use any of background features.
Also, I didn't see any crash report in Fabric's Crashlytics. So I think signal handler could not be called neither?
How to investigate this kind of problem?
These things can be tough, I know that from similar experiences. Without knowing more about your app I can only offer hints and no definitive answer, but perhaps this helps you.
The fallback and tedious approach to use direct logging with print and so on notwithstanding there are a two ways to try to "catch" a process.
However, first let me stress that "background" is not always the same and people unfortunately use the term often loosely. Depending on what state transition causes your crash you might run out of luck and have to simply experiment using manual logging. Apps can be in background, i.e. not in the foreground, but still running. This is usually the case when the debugger is attached, otherwise it couldn't do its job. Alternatively they can be suspended (or even terminated) by the OS. The debugger prevents this, which you probably already figured out.
The two things that might help you are:
If you're using background fetch, i.e. "coming back from background mode" as you describe it happens automatically you can activate the "Launch due to a background fetch event" option in your build scheme's "Run" configuration section.
Run your app from the Home screen, put it into background with the Home button and wait a bit (you've probably done so in the past already to get a feeling for when the crash would happen). Your app should eventually go into the suspended state (but you have no way to actually see that anywhere AFAIK). Instead of getting it to the foreground again via the multitasking UI, simply attach the debugger again via the "Debug - Attach to process" menu. This should get your app from the suspended state back into the background state, where the crash probably really happens (if it were to happen when coming from background to foreground you probably would have been able to debug it as usual). Hopefully the debugger has finished attaching to it in time, otherwise I'm out of ideas. :(
I haven't run into this specific problem myself personally, but I know background stuff can be tricky. Maybe this discussion also helps you (I took part of my info from there as well).
Run the app in debug mode on a real device. Press the Home button to send the app to background and continue the debugging. Then you can bring the app to foreground and keep debugging, or put a breakpoint at applicationWillEnterForeground.
You can't debug this on the real device. When the debugger is attached, your apps will never go to background mode in the real device.
You can try to debug this on a simulator.
Anyway please check your class attributes and set attributes to strong to make sure this is not happened by missing attributes.
I have read several StackOverflow questions that have FBApplicationProcess. Usually, this one happened by missing array or something when the app started.
Best regards.
I have gone through all the above answers and all have given proper answers. Though, I would like to share my point of view.
If the app is running on any iOS real device with debug mode and wire plug-in or even on Simulator, App will never go in the background.
If the app is running without wire plug-in or run without Xcode(directly launch the app in iPhone) and then put the app in the background, the app will be running in the background of next 3 mins. After 3 mins, the App will automatically be suspended and removed from the main thread. Now, when we open the app again, It will be considered a fresh launch.
If your app having any Background Capabilities ON, then your app will be alive even in the background, but you can't do any UI changes during that time.
To keep app alive in the background, Background Capabilities must be handled properly. ie. If Location is used in your app with 'While-App is in Foreground' condition, app will not run more than 3 mins in background. So, If you want to run your app continuously in background, you must have to represent proper reason in Info.plist file with Battery drain word, or else, Apple will reject it.
Ping me for more detail on your question.
Thanks.
Crash logs still available on your test device.
To get the crash log try the following steps:
Connect your test device to the Mac through USB.
Launch Xcode. Go to Windows > Devices and Simulators.
Choose your device from the devices section on the left side of the screen.
Select View Device Logs button.
Identify and select the Crash Log to see the contents.
I am having an issue where when I swipe up on my app to close in the simulator, the app will not open again unless re-run. I am getting an error Message from debugger: Terminated due to signal 9. I looked this up and read the issue may be related to CPU usage on the device but mine is very low. I am not even sure how to begin debugging as it is not clear where the issue is coming from. I am getting the user's location but I am doubtful that is causing the issue. I've also read a bit about background tasks causing this but am not confident this is my issue. I know this is a vague issue and I am happy to post code snippets once I can narrow down where the problem may lie. Does anyone know where I can begin debugging?
There's nothing to debug here. What you're describing is the expected behaviour of the task manager: swiping up kills a running app, in a way that cannot be intercepted or denied, using signal 9, SIGKILL.
You get the "Terminated due to signal 9" message, when your app gets killed. It might occcur when you swipe up and kill your app when it is running or else if you go to settings and change privacy settings for your app like changing location services or camera permissions for the app. It might also happen when you are debugging in your iphone device and the lightning cable is faulty, it will disconnect and the terminated signal will be thrown in the debugger.
I just added persistent data into my app and wanted to test it with my iPhone. When I quit my app (double tap home and swipe up), I'm unable to open it again (the icon freezes). When I try the same thing on the iOS simulator in Xcode, it crashes too. I get a SIGTERM error coming from my AppDelegate. Is this what is supposed to happen when the user quits while testing, or is this an issue with my data? Is there any way to simulate the user quitting and restarting the app to make sure my data is still there?
Thanks
This is not what is supposed to happen when the user quits while the Xcode debugger is attached (at least not anymore — this question is a couple years old after all).
If you force quit an app while running from Xcode (whether simulator or on a physical device) it just stops the debugger and you should be able to relaunch it without issue. The Xcode debugger will not be attached when you launch like that, but from Xcode you can attach the debugger to an existing process (Debug > Attach to Process).
Note, if run in Xcode and then you quit the simulator application on your Mac (or close the simulator's window) then you will get a SIGTERM error in main.swift. But this is not the same as a user terminating your app, nor is it comparable to a user turning off their device.
From what you're describing it sounds like there is a bug in your code that is causing it to freeze when launching when the debugger is detached or when it's relaunching after termination.
To simulate the user quitting and restarting you should be able to terminate the app from your device/simulator, and then either run it again from Xcode or launch it from the device/simulator and attach to the process from Xcode.
In some cases it may be helpful to put in some debugging code that pops up an alert / update some label at runtime to indicate the data persisted properly after the app re-launched so that you don't always have to have Xcode attached to diagnose problems in your app.
This is the correct behavior if you are running the app from Xcode. However, once you've uploaded/run the app once, you can test closing and reopening it. Simply stop the run in Xcode, go to your phone or simulator, and click on the app icon to open it. Unfortunately, you won't have a debugger log at that point, but you can see if your data persists.
I've been testing an app for iOS in Xamarin Studio, however whenever I reach a breakpoint or an exception is thrown and I stay there for a few seconds without pushing the continue execution button, the debugging session will close as the app will close on my device. This is due to the process mentioned here, as it is occurring during the splash screen, and if the app pauses too long there, it will close the app because it failed to scene-create. I was wondering if it is possible to disable this when debugging with breakpoints, because I would like to look at the data flow through variables and such.
As matt guessed, it is a Xamarin issue. The response to my inquiry to Xamarin was this,
Xamarin does not currently use a native debugger, thus watchdog is not
disabled. They are looking into alternatives, but for now a potential
workaround is to not do anything until you've returned from the
FinishedLaunching method (i.e. start your launch code in a timer event
for instance), and debug that instead.
Update: the status on this bug is "fixed for the next major release." as of 12/29/15
How can I solve this problem, I don't know that did it affect to my problem in this link My previous problem about Core data ?
This message will occur when I cmd+Q of the application.
Message from debugger: Terminated due to signal 15
and if who know the solution of my previous problem please tell me.
Message from debugger: Terminated due to signal 15 occurs whenever the user manually terminates the application (whether simulated in iOS simulator or on a provisioned iOS device) through CMD-Q (Quit) or STOP, which is toggled after you click on RUN.
In OS terms, signal 15 is a Linux enumeration for the signal, SIGTERM, which means signal terminate.
Message from debugger: Terminated due to signal 15 usually means that you quit the simulator while running the program.
I have same issue when i take screen short from simulator then terminated. This is xcode bug.
Just update your xcode version.
This only means that the system sent your application the kill signal. The system may do that for any number of reasons. It does not necessarily mean the application was killed due to memory pressure. In fact, this is very unlikely in the case that you describe. Most of the reasons the system might send a kill signal won't happen when the app is being debugged.
When the system kills an application it will track the reason and log it. If you are using a third party crash reporting service this will not capture the reason, and in fact can prevent a lot of critical information from being logged by the system.
Look for logs on the device. Watch the console log on the device when the issues reproduces - usually you will be able to see why it was killed. If it was memory pressure there would be a JetsamEvent log as well.
It is much more likely that your application is doing something "in the background" that it does not have a background mode or entitlement for. For example, it may be doing something past the background task assertion time limit, etc.
As far as your CPU and memory use, do not trust the gauges in Xcode. These are just an estimate and are often way off, and they do not capture the information you actually need (like dirty VM usage). Instead use Instruments.
https://www.reddit.com/r/iOSProgramming/comments/822id9/ideas_for_debugging_a_memory_leak_terminated_due/