I'm debugging an overuse of released objects using NSZombieEnabled. It's OK if you have an active connection with mac and are running from xcode4. But I'm hunting one bug that occurs after long run and I would like to test in on device without the connection. Just wondering is it possible to have some code for catching an event when a message is sent to zombie and then, ten display some NSLog with relevant information?
You can open up "Organizer" and view the console output. You get the same data that you would from the Console when debugging while attached to the Mac.
Window -> Organizer -> Click the arrow next to your device and select "Console"
Related
Is there any way to get a full iOS crash log when debugging?
For example... I have my phone plugged in, code open, run the app in Debug mode, and the app crashes on a specific line of code. Is there any way to get the crash log from that?
Or do I actually need to be disconnected from the debugger and computer, crash the app, and then get the crash log via the Organizer? I'd prefer to not do it this away.
I'm not aware of any way to get the equivalent of a crash log when the debugger is attached. I would say the general thought is that if the debugger is attached, you should be able to extract any information you need using the debugger itself. Some might argue that it's a feature that crash logs aren't generated when you're debugging.
Regardless, you should be able to get all of that info in the debugger. For all thread backtraces you can do:
thread apply all bt
And for library load addresses you can do:
info sharedlibrary
That seems to be the bulk of the useful information in a crash log.
Xcode has a built-in consolle. Show it by clicking this button http://imageshack.us/photo/my-images/46/schermata012455942alle2.png/ in the top right angle of the window.
When my app crashes, I would like to save the latest console for debug purposes (especially to read system messages such as unrecognized selector)
Is it possible to access the console programatically?
UPDATE:
I've found the answer in the documentations: using STDERR_FILENO.
"Logs an error message to the Apple System Log facility (see man 3 asl). If the STDERR_FILENO file descriptor has been redirected away from the default or is going to a tty, it will also be written there."
It sounds like you want to change the destination for the standard output stream. I've never tried that in iOS, but I'd expect to be able to do that using freopen(). Here's a SO question that may help.
You'll also want to build some debug feature into your app that makes it easy to recover the output. You could post it to a web server, for example, or have the app e-mail it to you.
When your app crashes in a device, a crash log is saved. When you plug your device in, launch XCode, open the "Organizer" window and click on devices. Then look for your device on the left, and click on "crash logs." Together with the information from the .dSYM file that's generated when you build, you can often recover how and where your app crashed. If you really just want to save the information in the console window of XCode when you crash, just click inside the console window, hit Cmd-A (select all), and Cmd-C (copy), then paste into a text editor window.
what happens to NSLog info when running on a device? Where does the text go? Does it get saved? Is it therefore a big overhead when running on a device, or does it effectively get sent to null?
Since Xcode 6 the device manager pane has been split into its own window. (Window > Devices, or Command-Shift-2.)
Once there, select your device, then show its log by clicking the disclosure triangle at the bottom of the window to the right of the sidebar.
Your device will continue logging even when it's not connected to your mac. To see the logs, you need to open Xcode, click the 'Window' menu item, and then 'Organizer'. Then select your device and then select the 'Device Logs' tab. For some reason (for me at least) viewing the logs seems flaky, so if nothing shows up, you may need to completely quit Xcode and restart it.
The text is logged. You can view the logs in xcode via the (almost-invisible) disclosure triangle in the Devices window as described in another answer.
You can also access the logs in a more usable view (including filtering) by opening Console.app on your connected Mac and selecting the device on the left.
There will be some overhead with logging, but considering the volume of logging that's going on all the time in recent versions of iOS, unless you're generating an awful lot of output (or spending time generating the messages), it's unlikely to be significant.
It gets written to the Console log on the device. You can read it in the "Organizer" within Xcode when your device is connected.
It gets logged out. You can retrieve it by connecting the device and looking in the organizing in xcode
Does anyone knows how to get crash logs from customers? Instead of manually asking them to sync and go to this directory and this directory and send it.
Is there any automatic way to do send a crash report to our server?
You can perform your own crash-logging with PLCrashReporter. Typically, you write the crash log to a file and then send it to a server the next time the app starts.
In order to prevent an infinite crash-reporting loop (there was one in an early version), you want to do things in a specific order:
Read the file to memory and delete it. (Hopefully this won't crash.)
Parse the crash report and send it to the server. (If it crashes now, the file has been deleted, so it shouldn't happen again.)
Finally, enable crash reporting (so if it crashes in steps 1 or 2, the crash isn't logged).
In any case, you should have a "Oops, it crashed! Do you want to send a crash report?" dialog. I think automatic crash-logging is permitted by the default EULA, but it doesn't hurt to be nice to your users.
If you're worried about losing reports forever if the user says "no", instead of deleting the report, you can do logrotate-style style renaming (i.e. rename report8 to report9, rename report7 to report8, ..., rename report to report0). Then have a "send last N crash reports" button (either set N=10 or count the number of reports), so even if they've accidentally disabled it (or they had no internet at the time), they can still send the report.
iOS 5 and later
Tapping Settings > General > About > Diagnostics & Usage will allow you to choose between Automatically Send and Don't Send.
iOS 4 and earlier
By default, opting in is a one-time decision. If you'd like to change your decision, you can reset warnings for your iOS 4 or earlier device so that you will be asked again.
How to reset warnings within iTunes
Connect your iPad, iPhone, or iPod touch to your PC or Mac.
Wait until your device has appeared on the left side of the iTunes window under Devices.
Right-click (Mac or PC) or Control-click (Mac) the icon for your device.
From the shortcut menu, choose Reset Warnings:
The next time you sync after resetting warnings, you should see:
To disagree and stop sending Apple diagnostic and usage information, click No Thanks.
If you don't see the window above
Disconnect your device from your computer.
Open an application on your device.
Press and hold the Sleep/Wake button until the red slider appears, and then press and hold the Home button until the application quits. If you're using iOS 2.x or earlier, press and hold the Home button until the application quits.
Connect your device and sync it with iTunes.
The option to agree or disagree to diagnostics collection should appear again.
Chearz;)
reference:
http://support.apple.com/kb/HT4305
In iTunes, with their device tethered, if the user control-clicks on the name for their device, they will be able to select "Reset Warnings". Afterwards, a dialog box will pop up when the user next Syncs their device asking if it's OK to send data to Apple. If they click OK, then iTunes will upload all the crash logs from their device to Apple's servers.
Afterwards, you should be able to find your crash logs in iTunes Connect, and download them yourself. New crash logs will appear if your app still has problems and the user Syncs again, all automagically.
If you are talking about normal AppStore sales, Crash Reports are available through iTunes Connect.
Just go to "Manage Your Applications" -> "Your Application" -> And click "View Details" with the version currently active in the AppStore.
You will then get the details of your application, including the crash reports that are send in by your customers.
I'm trying everything i can to get instruments to profile my app on the actual iphone device, but it won't work no matter what i do. I tried the solution from Does Instruments (ObjectAlloc/Leaks) require the simulator? but that didn't work. Most of the time i get nothing of use from the console, but one time i did receive this error:
Mon Aug 31 11:27:48 unknown
lockdownd[14] : (0x83d400)
handle_connection: Could not receive
USB message #13 from Instruments.
Killing connection
I'm not sure what could be causing this; has anyone else seen this and know a solution?
Same problem - it worked the first two times, then after that never again (even after restarting Xcode, deleiting the device, etc).
Eventually I resorted to:
Set XCode to display the Console
Run with Performance Tool
(instruments starts, and goes "BEEP"
with no error - Apple "forgot" to
include the error message, I think.
ARGH!)
Build&Run on device
Once the (gdb) appears in console,
go to Instruments and select "Attach
to Process" from the drop-down at
top
If you cannot see the name of your
debugging app, wait a second, and
try again
Eventually your app appears in the
list of alread-running stuff, so
select it
Hit the Record button
On subsequent runs, Instruments will remember the name of your app, but will show an error if you hit "record" too soon. So you just keep hitting record and doing "OK" on the process it tries to connect to until it stops messing around and does what it's supposed to.
So far (20 odd runs) this works everytime. Obviously, it would be nicer if it just worked properly, without this manual hackery, but Apple is reporting zero error messages even to system console, so there's nothing we can do!