I'm trying to set up a new organization to make sure that Debug (debugger not attached) builds' crashes are not dirtying the production Crashlytics. For Debug builds, I use a different organization and a different one for Release.
I am trying to achieve this by changing the API Keys & Build Secret. The problem that I'm facing is that with the new organization my crashes are not getting logged. I've double checked the API Key & Build Secret.
I see logs like these:
Crashlytics:Crash] Reporting is disabled
[Crashlytics] Crash reporting could not be initialized
The code I'm using to initialize Crashlytics looks like this ->
Fabric.with([Crashlytics.start(withAPIKey: my_private_api_key), Answers.self])
The crash reporting is working fine with the older organization, it's just the newer organization that's causing issues.
I've seen a previous question asked here and done a fair bit of researching + trial and error but I've not been able to find a solution.
Related
In an iOS project that uses Google Sign-In SDK (v5.0.2, added manually to the project, as well as GTM and Firebase), we have a crash that we could reproduce several times with a specific account on a specific device, when trying to sign in with a Google account.
The crash is:
** Assertion failure in +[UIAlertAction _actionWithTitle:descriptiveText:image:style:handler:shouldDismissHandler:], /BuildRoot/Library/Caches/com.apple.xbs/Sources/UIKitCore/UIKit-3901.4.5/UIAlertAction.m:42
The stack trace says the crash appears in
+[UIAlertAction actionWithTitle:style:handler:]
-[GIDEMMErrorHandler passcodeRequiredAlertWithCompletion:] + 556
-[GIDEMMErrorHandler handleErrorFromResponse:completion:]_block_invoke + 724
Poking with the debugger, it looks like UIAlertAction is passed a nil title, which causes an assertion failure.
The OS of the device is iOS 13.3.1.
I can't find an official way to report a bug in the Google Sign-In SDK, the Google issue tracker seems to be restricted to people with specific permissions, and they otherwise point to a forum that doesn't exist anymore, or to Stack Overflow...
The problem is that the resource bundle isn't being correctly linked in your project so the SDK gets a nil string for the action dialog which triggers the crash.
Until Google will gracefully fix it by providing a fallback string you can verify how you are linking the GoogleSignIn.bundle in your project
I've used Xcode's zombie debugger and managed to find this flag upon launch:
This crashed the app, and re-recording from Instruments caused the same result. Relaunching the app from the device made the app launch without a crash and subsequent launches from Instruments resulted in normal operation without flags or crashes.
Can anyone make sense of this or advise? I'm getting a number of "heap corruption" crashes in production. The reports are limited to a handful of users, but I'm afraid that number is growing.
It looks like the Parse SDK's latest release notes (1.15.1) addresses this:
-Adds polygonal queries
-Fixes memory leaks related with PFCommandCache
But my crash reports are coming from builds with this SDK version.
The Parse team has responded saying that a fix for this is coming to a new SDK release soon. :)
I am getting the following error messages when our production iOS app initializes:
[Crashlytics] Version 3.8.4 (121)
[Crashlytics] Running on iOS Simulator (iPhone), 10.3.0 (16E195)
[Crashlytics:Crash] Reporting is disabled
[Crashlytics] Crash reporting could not be initialized
[Answers] Initialized
[Fabric] Initialized with kit versions: {
"com.twitter.answers.ios" = "1.3.4";
"com.twitter.crashlytics.ios" = "3.8.4";
"io.fabric.sdk.ios" = "1.6.11";
}
Every subsequent call to log an event gets the following error:
[Crashlytics:Crash] WARNING: CLSLog has been used before (or concurrently with)
Crashlytics initialization and cannot be recorded. The message was: ...
The non-production versions of the app work fine running the exact same code but with different bundleIDs. Normally when the app initializes for the first time, then I see the app populate in the Fabric dashboard, but in this case the app is not showing up.
We have an Android and an iOS version of the app, and they both use the same bundleID, so I am wondering if there is a conflict because of that? I see the Android version of the app in the dashboard, and it seems to be working properly. This is an app that originally was a Xamarin app that compiled to both platforms, neither of which incorporated Fabric/Crashlytics. We have now written native apps on each platform, and both are using Fabric/Crashlytics.
Since this is a pre-existing app in both stores, we do not have the option of changing either app’s bundleID.
Make sure you initialize Crashlytics with Fabric before calling any Crashlytics methods:
Fabric.with([Crashlytics.self])
One step I routinely miss is to make sure you've added the build phase on your target:
"${PODS_ROOT}/Fabric/run" ${FABRIC_API_KEY} ${FABRIC_BUILD_SECRET}
and either replace ${FABRIC_API_KEY} and ${FABRIC_BUILD_SECRET} with your key and secret or add custom build settings for each.
There are apparently cases where Crashlytics does not auto-activate new apps so that they show up under your list of apps, even though everything is coded correctly and data is going to their servers. In this case, send an email to Crashlytics support (support#fabric.io) that contains a copy of the info.plist entries for the app in question and they will activate it for you. I have had to do this several times, especially with app extensions.
When I finally traced it down in my situation, the error was entirely correct, but not obvious.
I saw these errors in various testing targets where the code we tested was using a custom logging wrapper which called CLSNSLogv(), but the test didn't actually go through the AppDelegate and therefore did NOT initialize Crashlytics. After trying a few things I was convinced that it worked when executed as an app, but in our configuration it was not working under the unit test configuration.
I'll likely alter our custom wrapper to bypass CLSNSLogv() during testing anyway. The biggest benefit of using that is when crashes occur on devices, so we won't be missing anything.
I have a problem getting the new crash reporting in Parse 1.6 to work. The symptoms are the same as parse.com 1.6 crash analytics not working , but my reputation is too low to add my information.
1) I followed the quick start and guide to set up crash reporting and upload my symbols
https://parse.com/docs/ios_guide#crashreporting/iOS
https://parse.com/apps/quickstart#analytics/crashreporting/ios/existing
2) I'm following the instructions to generate a crash report by running the app directly in the simulator (iOS 7-8) and on the device (iOS 6) without a debugger attached. On the simulator I can actually see the minidump being created in Library/Parse/PFCrashReports.
3) When launching the app again I get the message "Breakpad Uploader: unable to determine minidump file length" and the crash dump disappears from the file system. So I assume Parse uses google breakpad under the hood, and the error is created by Uploader.mm because the call to stat() fails. I tried the same call in my own code and it succeeds there.
My gut feeling is that there is either a permission problems, or some other code locks the file while the uploader tries to access it. As the parse libraries are closed source it is hard to check anything, though. It is a bit suspicious that other people don't seem to have a problem with this, which may mean some other settings or configuration problem.
I just downloaded the lukeweber version of webrtcjingle, which I believe is just a branch of the google one.
I change the server and account setting on the demo and run it. It was able to log in and send/receive messages. However, When I tried to logout. The app crash.
I had a little debug on it, and found out the line of code that crash was in file txmppump.cc, function:
void TXmppPump::WakeTasks() {
talk_base::Thread::Current()->Post(this);
}
Does anyone have an idea what the problem is? I noticed that there is a fix on disconnecting problem issued caused by a race problem on the repo:
github bug list
However, I compared my code to the fixed version. They are the same. So I dont know if they are related or not.