I am building an iOS app using react-native. I am distributing the app using TestFlight. Every once in a while, I would see a crash reported on TestFlight. When I look at the crash info in Xcode, it doesn't tell anything about what part of JS code may have caused the crash. Below is a sample crash log I get on Xcode. Here App refers to my app name.
Since these crashes occur only intermittently, and the above stack trace points to very generic methods, I am not sure how to go about debugging such crashes.
Please share what would be a good strategy to debug these crashes.
Related
I've been developing a small "Cookie Clicker" style game for a while now and all of the sudden, the app will instantly crash upon opening. It doesn't crash on my own phone that I've been running the tests on, however, anyone that downloads it from TestFlight cannot even open it. It runs perfectly on the Xcode simulator as well.
Out of desperation, I completely backtracked the update that started the crashes (deleted all the new code for the menu I was working on) but it STILL CRASHES.
I don't want to copy/paste the code here because it is 16,000+ lines and I don't even know which aspect could be affecting it. I am using Xcode 11 and Swift.
If anyone has encountered this problem before and knows even where to start looking for the problem, any help is appreciated.
You need to download the crashlogs from Testflight, re-sybolicate them, and see where it's crashing. Download them from https://appstoreconnect.apple.com/ where you manage TestFlight. Here's an example:
Inside the download is generally two files:
crashlog.crash -- this is the actual crash
feedback.json -- any input provided by the user when it crashed
The .crash file can be re-symbolicated in Xcode as needed and you can see exactly which line caused the crash.
I develop an IOS SDK, which developers can implement it to their apps as a framework.
I’m currently using Sentry as crash analysis tool, and the related DSYM file (produced from my SDK project) is automatically uploaded to Sentry on every build.
But the problem is when someone’s app crashes due to an error on the SDK I’m developing, Sentry returns partially symbolicated crash logs that I can barely understand what has happened and where the crash has occurred.
Is there a way that I can get the fully symbolicated crash logs, without changing the app’s project settings and without uploading anything (app’s DSYM etc.) from the original app. (Since I don’t have the app, I’m only producing the SDK)
My project has the following build settings:
Strip Debug Symbols During Copy: No
Strip Style: Debugging Symbols
Strip Linked Product: No
I was sending the DSYM's to a wrong project. I set 'export SENTRY_PROJECT=proper_project_name' then the issue has resolved.
Here is the link of the issue;
https://github.com/getsentry/sentry-cocoa/issues/277
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.
How can I do to see the log of the crash in Xcode?, because when I have active the crittercism, with debugger mode, can not see the console log, always if I want to use xcode debugger, I need to disable crittercism and I think that is wrong.
Crittercism is right, it sends the report to the web service when open the app, but if I have the device connect to xcode, I can not see in the reports of the crash and crittercism does not send it to the web it.
I do not know if something is missing, exist something like a line that I need to add for this start to work ?
I've used Crittercism extensively for iOS and Android.
You should be able to see your Crash Logs in both Xcode as well as
within the Crittercism platform when your device is connected to Xcode.
Also, be sure you've configured your app for automatic symbolication.
see this article.
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.