I playtested the game that I'm making on my development iPad, while it was not connected to xCode. There were 4 instances where the game just crashed/closed.
If I remember correctly, these crashes should create a crash report which can be visible in the Organizer>Devices>Device Logs. However, upon checking this, I see only 1 (instead of 4) reports, most of which are marked as "unknown".
Is there a way for me to refresh the device logs, or make sure that my device does keep logs of all crashes that happened while not connected to xCode?
Related
I have a problem, when I test my iOS App on a real device or when I testing it in the simulator all is working as expected, but when I submit the app to TestFlight and I want to open it on my device the app is instantly crashing on launch. My last changes on the app was that I added the option that the user can pick another App Icon, nothing else. But now the app is crashing in TestFlight. Anybody has an idea what I can do?
Sometimes I get this error:
<NSError: 0x28227d6e0; domain: BSServiceConnectionErrorDomain; code: 3 (OperationFailed); reason: "XPC error received on message reply handler">;and thisMultiple RBSRunningReasonAttribute provided: 13 vs 20254. First one wins, but client should be fixed for assertion 31-112-6223`
I already tried to changes Scheme to Release but nothing changes still works on the simulator and the real device.
Question:
When iOS device is tethered to Xcode and crashed after building (app loaded in, was not a crash ON build), where is the crash log saved to?
Here's my predicament with some context:
I pulled a user's crashlog of EXC_BAD_ACCESS for my app. I symbolicated and I've narrowed it down to get a rough idea but now I'm trying to re-create the issue via building in Xcode to my iOS device (not simulator). Normally the app does not crash on load in (this crash isn't easy to replicate) but I've been able to have the app crash consistently with Address Sanitizer enabled, and it always crashed and points to a line in a thread with an men address -- not anything I don't already have from previous debugging.
However, one time I had a crash occur where it highlighted what func was called as well as every func called in the stack trace and what file this was all occurring in. In haste I hit build again in Xcode before I saved the output however... and now I cannot replicate.
The crashlog wasn't saved locally to my iOS device as I was still tethered to Xcode, and I checked ~Library/Logs/CrashReporter/MobileDevice but that did not contain them either.
I need find where Xcode would've saved these logs on my mac (if it did at all)?
Typically all the crash dumps are stored in Settings -> Privacy -> Diagnostics & Usage -> Diagnostics & Usage Data
Scroll down the list and find the crash file with your app name.
This link might be helpful - https://developer.apple.com/library/content/qa/qa1747/_index.html
I got this warning when running my application with HockeyApp integration:
[HockeySDK] WARNING: Detecting crashes is NOT enabled due to running the app with a debugger attached.
Crash reports are not sent and no alert is displayed when opening the app again.
Any one have any idea how to resolve this issue?
This has very simple reasons:
If you are running the app with Xcode attached, your app is connected to lldb, Xcode's debugger. When lldb is attached, it will of course do its job as a debugger and catch any exception or crash that occurs. This means that the crash can never reach the HockeyApp SDK or any other crash reporting SDK while lldb is attached at the same time.
The solution is also pretty simple. If you just want to make sure the SDK is integrated properly and will catch crashes, do the following:
Do a quick "Build & Run" to install the current version of the app on the simulator or device.
Click the "Stop" button in Xcode to stop the debugging session.
Manually start the app on the device or simulator by tapping or clicking the app icon.
Cause a crash.
Restart the app. Now the HockeySDK should process the crash report and show a dialog to approve crash log sending.
One thing to keep in mind: Make sure to not make the app crash immediately after app start as this would not give the SDK enough time to process and send the crash report before crashing again.
Hockey app sdk by default does not send report when a debugger is attached. There is nothing wrong with this.
It will send report when a archive build that release to ur tester cause a crash. I personally think this should and remain as this because you are trying to track crashes from your tester not when you are developing.
I've got an AppleWatch app that is working fine in Simulator and Device, but when I call openParentApplication, it appears that the parent app is crashing immediately because I see this in the console output:
The UIApplicationDelegate in the iPhone App never called reply()...
When I try to manually launch the parent iOS app in the Simulator it crashes there too immediately. I don't have time to attach the debugger (which is already attached to the AppleWatch app) to see what is crashing it. Note that the parent app runs fine when the AppleWatch is running and I'm using a real iPhone. I can also run the app fine on the Simulator when not debugging the AppleWatch app.
I've tried resetting the Simulator, but problem persists.
I'm just not sure how to debug this. Any help is appreciated.
Start an explicit background task in handleWatchKitRequest. Otherwise, your app gets killed before it reaches reply().
Refer to this post for a code example on how to create a background task.
In turns out that after commenting out all code in the parent app's didFinishLaunching and stripping almost all code out of the watch extension, the problem was indeed at a lower level.
The Simulator has a
Debug | Open System Log...
menu option that showed the crash logs, which contained:
Dyld Error Message: Library not loaded:
#rpath/MyCore.framework/MyCore Referenced from:
/Users/me/Library/Developer/CoreSimulator/Devices/A2061705-DDDF-477C-9AAA-E50GG43A6350/data/Containers/Bundle/Application/DEB7FB25-8233-4B9F-8DAB-9FF8AE42BF33/MyApp.app/MyApp
Reason: no suitable image found. Did find:
/Users/me/Library/Developer/CoreSimulator/Devices/A2061705-DDDF-477C-9AAA-E50FF43A6350/data/Containers/Bundle/Application/DEB7FB25-8553-4B9F-8DAB-9FF8AE95BF33/MyApp.app/Frameworks/MyCore.framework/MyCore:
mach-o, but wrong architecture
My Swift app has a few dependent Swift projects that are used by the app and extension. Getting the Swift frameworks to link has been a major pain. I've included the dependent frameworks (compiled in the same workspace) as embedded binaries. This works when running on the device, or on the Simulator, but not when running in this hybrid watch app + parent app Simulator context.
I changed the embedded binary references to point to the frameworks under ...DerivedData...Debug-iphonesimulator, as opposed to ...DerivedData...Debug-iphoneos, and the problem went away.
Still hoping the Swift framework story will improve.
Are you seeing an actual crash? That message has appeared for me plenty of times without the host app crashing.
99% of the time, that error appears because developers aren't opening a background task to complete their work in handleWatchKitRequest. Without the background task, the OS kills your app in the background before it has a chance to reply.
From time to time I'm getting errors that my iOS 8 device or simulator will sometimes not sync with iCloud (Drive). The following message appears (multiple times) in the output log:
CoreData: iCloud: Error: failed to receive initial sync notification
call back in 90 seconds
Only reinstalling the app helps.
Has anyone experienced the same issue or got some information about this?
I have seen that error (today) on an iPad running iOS 8. I fixed it by performing a reset (hold power and home/sleep buttons until the Apple logo appears). After that when I reran my app it synced immediately.
For the simulator it may be sufficient just to quit the simulator and relaunch. However, I have seen cases where restarting the computer was required.
I'm not sure what the cause of the issue is but hopefully the above help.