Parse.com 1.6 crash analytics upload failure - ios

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.

Related

How to find the place where the iOS code crashes using Firebase ? (when you can't reproduce the bug)

I'm using Firebase to get information about crashes of users of my application. Most of the crashes has no any useful information about code or place where it happens. All stack-trace and threads shows "Missing" text. Also I can't reproduce these crashes at my PC.
That crash is on Mac OS application, not iOS. My point of view is to look at that doc, (see "Build Your App With Symbol Information"). But may be on Mac OS apps that feature is not available.
https://developer.apple.com/documentation/xcode/building_your_app_to_include_debugging_information
What can I do to find the place it crashes ? See attached screenshot

Missing data in Fabric for IOS "Crashed: com.apple.root.default-qos"

I'm using Fabric.io to monitor and collect crash data for a IOS app.
I'm receiving now a lot of crash reports for this error "Crashed: com.apple.root.default-qos" but when I check Fabric to analyze it I got the following report:
where the stack-trace of the crash is missing.
What should I do to receive the complete stack-trace?
App uses some libraries imported using CocoaPods.
I'm attaching here also a screenshot with linked libraries:
I have discovered that this report was sent because of missing "Privacy - Face ID Usage Description" (NSFaceIDUsageDescription) in Info.plist.
I have no idea why the report was not complete, but after adding this key my app has stopped crashing.

iOS - Crashes not getting logged with log “[Crashlytics:Crash] Reporting is disabled”

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.

“JetsamEvent-2015-03-18-151504.ips” files are generated for crashes instead of .crash files

IN iOS 8.2 Device, my application got crashed,So to see the crash logs i connected my device to Mac (Xcode->devices->Device logs)
.There were no crash(.Crash) files generated instead “JetsamEvent-2015-03-18-151504.ips” files were generated which were of no use.And i am also using PLCrashReporter framework to collect crashes , but it is also not helpful in finding these crash files.Do anyone know why the crash file was not generated for my app crash?
Anyone have face this issue.
Thank you.
JetsamEvent log is so called Low Memory Report.
So, it is highly possible that your App was killed by system due to memory shortage.
References
- My app crashes and closes down and there is very little information as to why
- Understanding Low Memory Reports (*a little bit outdated)

iOS - AudioUnitInitialize returns error code 561017449

I have an app in the App Store which uses AudioUnit for recording audio.
About once a week or so I am seeing that for some users in the wild the call to AudioUnitInitialize fails with the error code 561017449 which is also 0x21707269 or "irp!".
What does this error code mean? I've been unable to find it documented. Also:
~$ macerror 561017449
Unknown error (561017449) at /usr/bin/macerror5.16 line 40, <DATA> line 1.
There have been few instances of this issue, but so far there appears to be no pattern of commonality as far as device and OS version goes.
I'm not including code as I don't think that will be helpful just yet. The code is working on variety of devices already. At this time I'm most interested in learning details about this specific error.
Thanks!
This is defined in AVAudioSession.h:
AVAudioSessionErrorInsufficientPriority = '!pri', /* 0x21707269, 561017449 */
and is described as "The app was not allowed to set the audio category because another app (Phone, etc.) is controlling it."
After wasting a lot of time I found that this issue is occurring in my device(iPad) just after debugging my current code in it without uninstalling the existing live app.
The record and play permission was creating the issue. So uninstalling then installing a fresh build magically does the job for me.

Resources