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.
Related
Im facing an issue that i am unable to debug.
If i open the app, it opens normally and works. But if i launch the app and close the app within 1 second and then launch the app again, it crashes without error message.
How do i debug this as Xcode loses debug connection if i close the app?
I tried putting exception break point but since xcode loses debug connection, it wont trigger.
This ONLY happens when a user does the above mentioned steps (open, close within 2 seconds and open again).
Is there anyway to find out why the app is closing and why there is no error / crash message?
Clarification : The crash happens when user opens the app, within 1 sec terminates the app by manually by swiping up from recents menu and tries to open the app again within 1 or 2 seconds. (Open -> terminate -> open)
Let us imagine that you run the app and quickly force-quit. Then, if you start your second run of the app from the Xcode debugger, hopefully, you should see your crash in Xcode at that point.
If that does not work, you might consider a crash reporting tool (e.g., Crashlytics, etc.). That will help you monitor and track crash reports that happen (for both you and your users) in the wild. If you do this, make sure you test the crash reporting system with some forced crash/report because an absence of a report could just be a result of a misconfiguration, which is easy to do because the setup of these tools takes a little work the first time you do it. Just make sure you have the crash report system working with a positive crash report before you draw any conclusions from an absence of a crash report generated by this particular bug.
That having been said, the way these crash reporting systems often work is they capture the crash and send it the next time you start up the app. It seems like there might be a chance that your particular crash (firing it up after having quickly force-quit it the first time) is happening so fast that the crash reporting system may not have a chance to send off its report of the past crash. (That having been said, these are still invaluable for capturing information about user crashes that happen during the normal use of the app, so I would consider them even if it does not help in this particular scenario.)
So, let’s imagine that you are still unsuccessful in catching your crash for some reason. The last resort is to consider sprinkling your code with Logger/OSLog statements. The nice thing about these logging statements is that you can watch these logging statements on your macOS Console app. See WWDC 2020 Explore logging in Swift.
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.
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"
so when i'm running my app using XCode and I can see that my app gets "program received signal 0".
However , the background thread are still running. why is that ?
Second, I can't seem to find any solution to this problem.
I assumed it might be memory leak, but I see nothing special using LEAKS (instrument).
When I run the app on the device(without XCode) and then try to see the device crash inside the organizer, most of the times there is no log (I guess maybe because the app is still running and only the main thread crashed) and while there is a log, my app function are only hex addresses without names.
What other options do I have to solve this issues ?
Thanks!!
I've found that sometimes these errors are caused by trying to access deallocated memory. One great tool to debug these issues is NSZombieEnabled. Here's a link to a good explanation of how to use NSZombieEnabled: CocoaDev: NSZombieEnabled
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!