I've been using Xcode to develop iPhone Apps for a couple of years now. In the last couple of months I've updated to Xcode 4.2 for iOS 5 development.
On previous versions of Xcode I've found it very rare that I get a crash without any log of where the error happened. With Xcode 4.2 / iOS 5 I find that I regularly get crashes without any log. I just end up with the code stopped in main.m with a message like "program received signal SIGABRT" (or a couple of other messages) but no log messages at all. (I'm looking in the "All Output" window at the bottom of the Xcode gui).
For example, my last one was where I used the initWithNibName:bundle: method but typed in the incorrect nib name. The code passed this line without error, but when I got to the pushViewController:animated: method the code crashed with the SIGABRT message but no log messages. It took a while for me to find my typo...
I'm sure in previous versions of Xcode I would see a far more informative message...
Is there something I'm missing in Xcode 4.2? Should I enable some extra debugging feature? Any way to get it to give more useful crash information? Or is this a know problem with iOS 5 / Xcode 4.2?
Thanks for any pointers...
You are not alone, I have found this too. I often find there is not enough information in the log to diagnose the crash with the lastest xcode. I have two tips that might help.
Run on the actual device. I often find for some reason I get more detailed logs when it crashes on the device.
Worst case, you can go into the organiser and check the crash logs of the device, this will give you what thread crashed and what you call stacks looked like when it crashed.
Switch between the GDB and LLVM compiler and or debugger. I havent experitmented enough with this but I believe this has helped on occasion.
Related
This question already has an answer here:
Weird UIAccessibility Crash On Ipad Mini 2
(1 answer)
Closed 5 years ago.
I have taken over a code from someone else and the source code is written in Swift. I have made my changes but when I added the Crashlytics for crash reporting, I keep on seeing UIAccessibility crashes. Mainly 2 crashes keep repeating,
UIAccessibility _copyAttributeValueCallback
and
UIAccessibility _copyMultipleAttributeValuesCallback
I have searched every last thread of stack over flow with the keywords Swift and UIAccessbility but still cannot make out why it's occurring. Any idea what I am missing here?
Edit: This is the crash report from Crashlyitcs.
I was struggling with this same issue and have concluded it's not a crash and an issue with Crashlytics. It was pointing to the AppDelegate class definition, no actual code. I recently uploaded a copy of my app to test with TestFlight as a release version only giving myself access. I launched it a few times had no issues using the app but went back to my debug version. The next time I checked Crashlytics, my error free to me testing showed 7 of these crashes on an iPad Mini 2 while I was testing on an iPhone 6S. No one else had access to this particular build.
Also, a new release to some testing customers showed this error on my latest release for a customer who hadn't yet downloaded it. Strange things are certainly afoot at the Circle K for this particular crash.
In addition, Apple shows none of these crashes! As I type this I'm realizing these crashes only show up on builds distributed via TestFlight. We use Crashlytics for internal testing and TestFlight to test with clients prior to release. Does this match your experience?
I have an app that is crashing on the device (works well in the simulator) which leads me to assume that maybe it's a memory issue...
When it crashes, there is no message whatsoever reported in the console.
It does not crash each time a certain action is taken, it crashes at different points of time always after the app has been running and in use for some time.
I know I'm supposed to ask a more specific question - but if anybody is able to tell me where to start trying to track down a crash that does not report in the console, I would really appreciate it!
I am now using the latest version of XCode (4.2)
Thanks in advance...
It very-well could be a memory issue. If that is where you want to start your diagnostics, you can use the built-in Xcode profiler. In Xcode Product->Profile will get you started.
Maybe setting the NSZombiesEnabled value to YES in Project -> Edit Active Executable -> Arguments -> Variables is also helping; this will show you memory access errors based on accessing released objects. But in that case you should at least get a SIG_ABRT or BAD_ACCESS error ...
You can also log when the app receives a memory warning in the didReceiveMemoryWarning functions of your view controllers - this is called before the system is throwing out stuff when memory gets low. That of course could lead to a crash with nothing showing.
First, relax.
Then read this Technical Note.
Now, follow these steps:
From /Users/<username>/Library/Developer/Xcode/DerivedData remove all folders.
From /Users/<username>/Library/Application Support/iPhone Simulator remove all folders.
Clean your trash.
Remove app from device.
Build and run application on device.
Follow the steps that leads toward a crash.
Now, go to XCode->Window->Organizer and select "Device Logs" your device from the DEVICES pane. Select the most recent of these which has your application's name. Wait for XCode to symbolicate the crashlog. There are two possibilities now:
Its a low memory crash.
Its a memory management related crash.
If its option one, profile your application in Instruments.
If its option two, you should see the stack frame where you application is crashing (or your module's stack). This SO question will be very helpful
If you cannot understand the output (or you think the crashlog is not symbolicating - or that its not your code that's crashing), please post the crash log's crashing thread's stack here and I'll look into it.
PS: in the first section we do the first two steps to make sure there are no left-over .app/.dSYM files which might hinder symbolication later in the process because XCode symbolicator is not that intelligent.
I am getting an assertion error when I launch Xcode 4, which I just installed. I have looked on Google and Stackoverflow, and I could not find anybody with the same problem as me. As soon as I open Xcode 4, it shows me the welcome screen. I try to open a project, and Xcode gives me a message saying I can continue using Xcode in an inconsistent state or I can crash Xcode. When I click on more details it says "ASSERTION ERROR" followed by some other debugging info. I can't copy it because when I try to highlight it Xcode freezes completely.
Any suggestions?
NOTE: This is different from other people who get this error when they build, I am getting this when it is LAUNCHED.
Could it also be because I am continuing a project from the previous version of Xcode?
[UPDATE] I have solved the problem. If you are also encountering such an error, try reinstalling Xcode 4. If you continue getting the same error, then follow the advice of #mrueg.
Xcode 4 has various bugs, and the assertion error is just a general warning that an inconsistency was detected.
The best way to get more info on the actual error that happened is to crash Xcode when you get the error and then show the details.
It probably also makes sense to send the crash report to Apple so they can fix the bug.
It is probably best to keep using Xcode 3 (which is still downloadable for the newest SDKs) and wait for the next version of Xcode 4 if your project crashes it.
Debugger is telling me this, when I run my app on device:
Program received signal: “EXC_BAD_ACCESS”.
mi_cmd_stack_list_frames: Not enough frames in stack.
mi_cmd_stack_list_frames: Not enough frames in stack.
I don't get information about where in code that happens. That's all I get. Any idea what that could mean?
The app crashes after that. When the device is not connected to the mac, it still crashes, so not a debugger problem.
Building on the 4.0 sdk onto a 3.1.3 phone caused this for me.
Fixed by weak linking UIKit in the target.
EXC_BAD_ACCESS happens when a message is sent to an object that has already been released.
I've seen "mi_cmd_stack_list_frames: Not enough frames in stack" before when trying to release something that's already been released as well.
My suggestion is to set the NSZombieEnabled environment variable and see which released object you are trying to access.
This site has a great tutorial on it:
http://www.codza.com/how-to-debug-exc_bad_access-on-iphone
I've seen this caused by at least three different kinds of problems:
• As described in the other answer, overrelease errors can do it.
• I had it happen when I was upgrading an app to use iAd and IOS 4.0. I think the problem was that I tried to use the iAd framework in the 3.0 version of the app as well, which of course isn't possible because iAd is only around in 4.0 and above.
• I had it happen when I removed a bunch of stuff from an app and recompiled, but vestiges of the old stuff were still around on the simulator. Resetting the simulator cleared the problem. What I was removing was the Flurry API. I'm afraid I don't know what, specifically, in there stuck around and caused the problem.
I have the same issue. My solution is:Quit the Xcode and then restart it after waiting some time.
I've got such a message when was trying to launch an app on iPhone under iOS 3.1.2 with a string like that
Class messageClass = (NSClassFromString(#"MFMessageComposeViewController"));
At the same time that works well when I use a device with iOS 4.
So I can assume that app could crash when start running on device if there are any references to iOS4-only classes.
Creating a new project and copying all the existing files in it solved this problem for me.
Are there any crash logs generated by iPhone Simulator?
the Simulator crashes a lot but not leaving any traces in Console... the crash log will be useful.
The console will show the NSLog() output from an app running in the simulator. The crash logs are saved to file.
I have found some in my home directory under
~/Library/Logs/DiagnosticReports/
They have a file extension of .crash
Something I haven't yet figured out is how to get them to generate even if the debugger grabs the EXC_BAD_ACCESS signal.
Update
Currently, (OSX 10.11.6), the .crash logs in ~/Library/Logs/DiagnosticReports, are when the emulator itself crashes. Logs for an app crashing (but the emulator device is still running fine), are in:
~/Library/Logs/CoreSimulator
Per crash, there is a sub-folder with a unique id. Sort by date, so that your recent crash is the first sub-folder. Inside that, start by looking at stderr.log and system.log.
Also directly under CoreSimulator, see CoreSimulator.log and Simulator.log.
I am pretty sure that you can see this in the OS X Console app located in Utilities. If I'm wrong though, be sure to vote me the heck down so I delete this.
UPDATE:
Specifically (as of OSX 10.11.6),
When an app crashes on emulator, a subfolder (with a unique id) is added to:
~/Library/Logs/CoreSimulator
Within that, start by examining stderr.log and system.log.
When the emulator itself crashes, a subfolder is added to:
~/Library/Logs/DiagnosticReports
Don't confuse this path with
/Library/Logs
(lacking ~ at start), which has different reports about your mac.
Here’s something that worked for me in a special case... My app was crashing with SIGKILL as it terminated. I would see the exception in main.m for a few seconds, and then the app would finish terminating – thus, no chance to get the back trace.
I did a lot of searching on “where does simulator store its crash logs” and never managed to find an answer. However, the following trick came in quite handy and I was able to grab the crash log on the fly:
Basically, open /Applications/Utilities/CrashReporterPrefs.app and change the setting to “Developer”. This will cause CrashReporter to display a popup with the crash log after your app crashes.
I found this in the “Viewing iOS Simulator Console and Crash Logs” section in this doc from Apple:
http://developer.apple.com/library/ios/#documentation/Xcode/Conceptual/ios_development_workflow/125-Using_iOS_Simulator/ios_simulator_application.html
The crash crash logs will appear under ~/Library/Logs/CrashReporter.
If the iPhone simulator program crashes (not the iPhone app running within the simulator), then there will be an entry for iPhoneSimulator.
If the iPhone App within the simulator crashes, the crash log will appear with the display name of the app.
When Xcode gets crash logs from a connected device, it stores them in sub-folders of ~/Library/Logs/CrashReporter/MobileDevice
This is much more reliable. In only a few steps I was able to find the source line number & method name:
cd to the dir having the .app & .dSYM files
run /Developer/Platforms/iPhoneOS.platform/Developer/usr/libexec/gdb/gdb-arm-apple-darwin MyApp.app/MyApp
set print asm-demangle on
set print symbol-filename on
p/a 0×00015c64 -> address got by opening the crash log in “Console” app or just double clicking the the .crash file.
For me, it was an expression that I had added to the debugger watch window. When a breakpoint was getting hit, the bad expression was causing XCode to segfault.
You may also want to take a look at this related answer: https://stackoverflow.com/a/14984297/679240
None of the answers above worked on the "Big Sur" OS version. The only way to find the log was through the "Console" app (Application/Utilities/Console)