Where does iOS console output go when it is truncated?

Question

Created Dec ’15

Replies 5

Boosts 0

Views 5.7k

Participants 3

I'm trying to debug an iOS app that sometimes exits "mysteriously". It dosn't happen while connected to Xcode, only when running alone on an iPhone device. I'm writing lots of debug information to files in the tmp directory but after the mysterious exits nothing helpful is contained there. It's as if it's terminated by iOS with no involvement of the app code itself. I would expect the iOS console might give a clue about what's going on but so far it's always been cleared and restarted sometime after the exit happened. IOW the earliest date/time in the iOS console is a little after the app exited, so nothing from the time of the exit is there.

The app uses very little memory and (according to the memory instrument) the memory doesn't grow with time. Of course that's measured only while the device is connected to Xcode and it never crashes then. It's cpu use is typically in the 10-20% range.

Q1. In OSX and Unix when the syslog file is cleared and restarted the old file is archived somewhere so it's available for a long time. Does that happen in iOS? How can I find and read the previous console file?

Q2. What causes the iOS console file to be cleared? It usually contains many hours of output but the last 4 times my app crashed it had only about 45 - 60 minutes of output and the crash was always just before the earliest console output. I'm wondering if whatever is crashing the app is also clearing the console output, although that seems unlikely.

Q3. Two of the last four exits happened when a phone call came in, but at other times incoming calls didn't crash the app. Does that give any hint about what's going on?

Q4. Is there a way to somehow persist the iOS console (i.e., take a snapshot) so I could look at a copy later?

To give some context: this is an app that records heart rate vs. time, both on a graph on the screen and also in a file for later use. The heart rate data comes from a bluetooth chest strap. For testing and debugging I'm using it myself in the gym. 9 times out of 10 it works fine for the hour or so while I'm exercising but 4 times lately it crashed. When it crashes I look at the iOS console as soon as I get home using the console view in Xcode but that's typically at least 45 minutes later and by then the output from the time of the crash has been cleared away. I wish I could look at it right away on the phone but I don't think that's possible. This is iOS 9.1 and Xcode 7.1.1. The app is a mix of Objective-C and Swift.

Boost

Answer 1

iPad_dev OP

Dec ’15

why are you relying on the console for debugging? i wouldn't and don't.

why not use NSLog or your own class? or what i do is atomically write to a file. context of atomically, as far as ios allows which it seems is pseudo deterministic but not it's not real-time like QNX or VxWorks.

q3, probably dependent on how big your log file was. your app needs to be aware that if another event has priority, phone call etc, your app will get dumped into background. look into the appdelegate.swift there are defined functions/events for saving data.

q4 probably, i would look on stackoverflow.

0

Answer 2

NewYorkRobert OP

Dec ’15

I am using NSLog all over the place. It's output goes to the console when not connected to Xcode (tell me if that's not true), so I want to see what's in the console. I'm also writing to my own debug files but so far I haven't found what to write that's helpful.

Also this problem feels like it might be something external to my app and evidence of that might be on the console output. Like maybe a bluetooth event, wifi event, cell phone event, something suddenly spiking cpu or memory.

0

Answer 3

Documentation Engineer OP

Apple

Dec ’15

If the app is truly crashing then there should be a crash log for it. However, what you're describing sounds like it might just be that the app is getting terminated in the background when it's suspended. I would recommend reviewing the details in The App Life Cycle to make sure you understand what the expectations are. In particular is this paragraph:

Suspended apps receive no notification when they are terminated; the system kills the process and reclaims the corresponding memory. If an app is currently running in the background and not suspended, the system calls the

applicationWillTerminate:
of its app delegate prior to termination. The system does not call this method when the device reboots.

So if your app is being terminated when it's suspended you just need to be prepared for that. If it's actually running in the background, you should be getting the applicationWillTerminate: method. Do you have that implemented? If not, I would implement that and then log something to a file in your own app container that you can then get later.

You should not rely on the console output, and instead should do your extended logging to a file in your app container. You don't have any control over the system log on iOS so I would not rely on that.

Based on your comment about the incoming call, my guess is that your app happened to be in the background, suspended, and then when the call comes in a number of things happen (the underlying telephony stack is invoked, the UI gets involved to put up the ringing indicator, etc) and the system may suddenly come under pressure that it responds to by killing apps, and yours might be one of the ones that goes.

Sorry, that may not help get to the bottom of it, but hopefully sheds a little more light on some things.

0

Answer 4

NewYorkRobert OP

Dec ’15

I think I have a fair understanding of the life cycle. I do implement applicationWillTerminate and I have an NSLog statement in there but that output would go to the console which is lost. Following your advice I'll log something to my own file in applicationWillTerminate and not rely on console output. Maybe that will clear things up. Many thanks.

0

Answer 5

iPad_dev OP

Dec ’15

the app delegate will help,

i would also add in your plist the following at least for debugging

Required background modes

item1 -> App communicates with an accessory

Application does not run in background -> YES

Application supports iTunes file sharing->YES so you can dump files in the docs dir

0