I am getting the following crash reports from some recent apps deployed to the app store. I am not sure what is causing it or how to fix it.
Could not load 'monotouch' for registration. This could be due to an
outdated assembly kept by the simulator, location:
/private/var/mobile/Applications/1BEDC27F-B313-4240-8490-EAD680F8E78A/PhotoTour.app/monotouch.dll
It refers to the Simulator in the error, but the app from the app store.
The message itself refers to a condition that was known to exists only in the simulator. The iOS Simulator does not remove old files (it only updates them).
In recent MonoTouch versions there's another fix now that should prevent even this message to occur (on simulator builds). It's very unlikely that the same condition (stale binaries) is occuring on devices.
The exception behind the error means that that the types inside the assembly (monotouch.dll) could not be registered properly. This should not happen, even less randomly (i.e. if it occurs it should be systematically on every execution and on every device, including when testing). Since registration occurs everytime at startup it's hard to see why testing (and Apple app approval) has not catched this.
Please fill a bug report including the exact version of MonoTouch being used and attach a log of the (release) build (add -v -v -v so we'll get more details about the build). Also attach the logs from where you gathered the above message - other lines of the same logs might gives us some clues.
Related
I'm looking for logs of the Xcode application itself. Not logs of my iOS app or device.
I've been doing a bit of experimental work with the storyboard source code xml. Sometimes I'll get a random crash of Xcode or a message like "The document Main.storyboard' could not be opened. Could not verify document content" (This is not git conflict related)
I'd like to look in the logs to see if it gives a clue as to what part of the xml is causing these crashes or errors.
Note: I was able to find some additional crash information by looking in the 'console' app. But not error information.
Thanks.
There are a few things here. First of all, I do not believe Xcode writes any dedicated log files (as opposed to, say, Android Studio, that puts logs under ~/Library/Logs/AndroidStudio2.2). Having said that, there are a couple of places to get them:
1. The device logs
Xcode uses system logging to log its messages to the console. If you open the Console app, find your macOS device in the Devices list and look at the messages. By default, it shows all the messages from all the apps, but you can filter our by PROCESS - Xcode (filtering is a bit unintuitive, you first search for Xcode which generates ANY|Xcode filter, than you select ANY and change it to PROCESS).
The one problem with the Console app on macOS Sierra is that it only shows logs from when you started the Console app, not earlier. You can use the log command line to collect previous logs (e.g. sudo log collect --last 1d). You can find more information about it here.
Alternatively, you can actually start Xcode from the terminal (by typing /Applications/Xcode-beta.app/Contents/MacOS/Xcode in the terminal window). If you do that, all the logs will be written to the terminal console.
2. The Diagnostic Reports
These (also accessible via the Console app) will contain crashes that Xcode itself doesn't log (there are some cases where Xcode will die silently, but the Diagnostics Reports may still contain the error along with the callstack and other useful info). Note that there are two places where Diagnostic Reports are stored, under ~/Library/Logs and /Library/Logs - make sure to check both.
I've received a crash log in iTunes for:
Dyld Message: Library not loaded: #rpath/Foo.framework/Foo
There are several of these, each for a different framework that is included in the app, although there isn't one for every framework.
I understand what a "library not loaded" crash means, and how to fix one that is happening on every run of the app - it's just "add the framework to copy files, because you forgot to before". My impression is an app should either crash with this error every time it is run, or none of the times it is run - either the framework is included in the bundle, or it isn't.
A few more details:
I can't reproduce this, and the vast majority of users seem to be getting along fine.
There are crash reports for both workspace (normal "Copy Files") and Carthage (carthage copy-frameworks) frameworks.
What should I do to investigate and fix these crashes?
This appears to happen when the device itself runs too low on memory. It's an iOS bug that should be fixed in iOS 9.3.2 (released May 16, 2016). The users that experience have many apps crashing for them during launch. The only way they can solve it is by restarting their device.
The issue is caused by apps using too many (third party) Frameworks. So you can either remove Frameworks (by for example copying third party code into your project) or wait for users to get the iOS update with the fix.
We're using TestFlight to send out pilots of our app.
There's a part of the app that is crashing, and we had a lot of trouble reproducing the crash. The code their is fairly simple.
It turns out that the users who got the App via TestFlight get the crash, while if you build the app and install it using the IDE it doesn't crash!
Anyone have ideas about what might be causing this?
Any ideas for workarounds? We don't want to stop using TestFlight.
Make sure to build your app in Release Mode not in Debug. The app may only crash when in Release.
The first thing I'd try is to map the crash stack trace to function names in your application. This may yield useful insight into the nature of the crash:
As soon as a crash is reported request the crash log. This can be obtained through Xcode's organizer or if that's not an option it can be screen-captured from the iPhone's Settings -> General -> About -> Diagnostics & Usage -> Diagnostic & Usage Data. Scroll to the app name or the section LatestCrash-AppName.plist.
Although you can in theory symbolicate a crash, I find the procedure described below a foolproof way to get symbols from the stack. Convert all stack addresses for the crashing thread into method names.
Optionally request the iDevice syslog. This may include assertion failure messages which are also invaluable. Note that this should be done as quickly as possible as the syslog only holds so many entries before they get dropped. You can use the Organizer or the cmd line idevicesyslog to obtain this.
Manual symbolication:
This will work as long as your builds have debug information.
Obtain the _exact_same_ .ipa that crashed. If you didn't save it you can download it from the device by using iFunBox or the cmd line ideviceinstaller utility.
Unzip the .ipa
Run the following command on the executable file (Payload/AppName.app/AppName):
otool -tv AppName.app | c++filt > listing.asm
Wait while the previous step completes (may take a while). The generated listing.asm file will be several megabytes long.
Using an editor that can handle large files search listing.asm for the addresses listed in the stack trace. Note that the addresses may be a few bytes off (usually pointing 3 or so bytes ahead). Also, addresses that aren't found in listing.asm indicate addresses in iOS libraries. Ignore those for now.
Of course, if you're able to symbolicate, you can skip this procedure.
Good luck debugging!
We had a similar problem. The issue with us was static libraries. When we built the app from scratch and went to testflight, it was crashing but from the IDE it wasn't. The crash was because the static libraries did not get included when doing a build, but was getting included if I connected the iPad direct and used XCode to install.
A simple test will prove this:-
1.) Instead of building from IDE, create a .app file and then load it via iTunes and check if you are getting the crash.
We worked around this by creating the .iPA manually, that is creating the .app then making a Payload folder and putting the .app in it along with the info.plist.
Then things began to work in Testflight as well.
I have a project I can successfully build/install using developer/debug to a device or simulator.
When I make an ad hoc build i can build-run onto the simulator, but not onto the device.
I'm trying to perform a direct install because the ad hoc installed app is crashing (nil added to array) where the debug version is not.
I also have tried to attach to the running ad hoc installed app. The app will run indefinitely (but crash if i perform a particular use case.) But if I attempt to attach to the running app, it will crash.
It happens to be a Box2d/Cocos2d application - but i don't have any reason to think they are the cause. Xcode 4.3.2, iPhone4 iOS 5.1
the message when build-and-run is attempted:
error: failed to launch '/Users/bshirley/Library/Developer/Xcode/DerivedData/foo-bar-evrbckppmbsspqhezhleaxkmymxn/Build/Products/Adhoc-iphoneos/foo-bar.app/foo-bar' -- failed to get the task for process 6892
Anyone have some insight into the problem or tracking it down?
Edit, I thought I'd add some key words so searches might be more likely to find:
One issue with diagnosing the post-mortem crash was that the stack trace was not symbolized in the Device Logs of the Organizer in Xcode. That left me with 6+ deep stack trace w/i my code and no real reason to determine where it actually was.
If it is a release build, the app will (in a default setup) have a flag preventing outside processes from hooking into it (for security reasons). This includes the debugger. If you try, you will get the exact error message you indicate.
EDIT Sorry, small error. A release build alone will not cause this. A build with an adhoc certificate will cause this, because it is meant for final install on a device (not debugging).
If borrrden is correct (and it seems reasonable that he is, connecting one app to a signed running app would be a security issue), I can't actively debug the adhoc app.
The most useful thing i found for tracking down this issue, is Build Settings -> Symbols Hidden by Default - this value is only NO for debug. Setting it for NO on adhoc allowed me to see the entire stack trace when inspecting the Device Logs in the Xcode Organizer.
That led me to the particular method that was invoking the crash causing issue. Which led to the question why wasn't it crashing in the debug build. Didn't have time to diagnose that, just fix the problem.
My app runs fine on the simulator. However, when I run it on my iPhone, it gets as far as displaying the splash screen and then just stays there. It's an iPhone 3GS and the software version is 5.0.1. That's what happens when Debugger = None. When Debugger = GDB, I get an error message, 'Thread 1: Program received signal: "SIGABRT"', which I have learned can mean almost anything. I'm running Xcode 4.2.1.
I'm coming off a long hard night of battling with this error message, which appeared seemingly out of nowhere in a stable mature app. I tried to roll back with time machine, I deleted the Derived data for my project in Organizer a few times and did some of the other stuff recommended in this thread.
XCode 4 hangs at "Attaching to (app name)"
It got ugly. For a while, I couldn't even reboot my machine. Eventually, I was able to relaunch finder and suddenly the Simulator was working again. Two more pieces of information, I used to have to click allow in two dialog boxes when running on my phone but now it's only one (the one about code signing, I forget what the other one was about). Second, I find all the build architecture target stuff confusing but I set all my Base SDKs to be latest iOS. Lastly, I tried Product --> Clean and then Build but that didn't fix it. As you may have gathered, I'm getting my butt kicked. Any help would be much appreciated.
Dessie
Many times I have experienced Xcode going "crazy" with a physical device connected. At times I saw the behavior you describes; other the app simply refused to start;
In all of those cases, I could fixed it in either of two ways:
disconnect the iphone and connect it again;
reboot the device.
This is a very common problem that is easily fixable.
1) remove the app from the device
2) reboot the device
3) close Xcode and you must restart, logging out will not work