I have created a Xamarin.Forms barcode scanning app with Android and iOS projects. The Android build appears to run fine, but the iOS build occasionally crashes and I am struggling to pin down the cause, as no crash log is produced and no exception is reported in the application output.
Under heavy load (non-stop barcode scanning) the app crashes after typically 200 or 300 barcodes have been scanned.
I am puzzled how such a crash can occur, leaving absolutely no evidence of its cause. Is there somewhere else I should be looking for the evidence, apart from within Xcode's Devices window? Shouldn't I expect an exception to be reported in the application output, while debugging?
I have implemented logging handlers for AppDomain.CurrentDomain.UnhandledException and TaskScheduler.UnobservedTaskException but they don't appear to be called. Is there some other way I can instrument my code to trap the cause of this crash?
Many thanks for your advice,
Tim
To get some output I always hit the continue button in visual studio debugger. The application stops, and for some reason I can see an exception in the output. Hope this helps.
Related
After working just fine on both iPhone and iPad for a month, my Xcode 9 app has consistently started crashing causing me the following fatal problem: When I build & run it on an iPhone (simulator or device) Xcode completes loading the app and then crashes too fast for me to copy/paste the error from the debugger. When I run on iPad it works fine leading me to believe this is a result of something related to the split master/detail view.
If I use either an exception breakpoint or an "all C++ exceptions" it will stop at the AppDelegate class and crash if I hit play. If I use only an "all Objective-C exceptions" it will crash as before.
In the debug view hierarchy I get the following errors as well:
Error: Unable to capture view hierarchy.
Details: Log Title: Data source expression execution failure.
Log Details: error evaluating expression “(id)
[[(Class)objc_getClass("DBGTargetHub") sharedHub]
performRequestWithRequestInBase64:#"...
Log Method: -[DBGDataSourceConnectionLibViewDebugger
_executeLLDBExpression:forRequest:onPotentialThread:iteration:]
_block_invoke_2
Method: -[DBGViewDebugger updateDebugHierarchy]_block_invoke_2
I have tested other apps and this issue is unique to the app I am working on. Any ideas or debugging tips for how to proceed? I might just have to redo this whole project again if I can't even find the root cause of this! Appreciate any help.
Quick solution: Reset Simulator Device
I managed to resolve the above issue thanks to some serious digging. First, to resolve the instantaneous crash problem, I set a breakpoint at every line in the app delegate. That allowed me to narrow the error to a memory handling problem. From there I started running the code on one of each device available, and realized the crash only occurred on devices I had used earlier in development. Resetting those devices solved the problem.
The core issue here is that when you clean/rebuild your xcode program, it updates the app code on the device, but not necessarily the data model information. So when I changed my data model by including new data and renaming old data it was not properly updated.
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 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 have a project built for iOS 7 and it worked fine so far, but after a Git merge, some settings or something became corrupted and exceptions are not outputted to console anymore. So the "Terminating app due to uncaught exception" error message is never displayed in console. I've tried the project on both the device and the simulator, same thing. I cannot find the reason why is this and how to fix it and I am humbly asking for your help.
The facts:
debugger is working and running,
debugger stops and highlights correct line,
all exceptions breakpoint is active,
NSLog commands are working,
po command in lldb is working.
What I have tried before asking for help?
Cleaning (including build folder) and rebuilding project,
Restarting Xcode,
Restarting OS X,
Reconnecting device,
Rebooting device.
What else can I do? Thank you for your help!
I ran into this issue when trying to debug an autolayout crash. Not sure if this applies to all cases, but here's my solution:
I did some hunting, and came across this link:
Investigating NSExceptions with LLDB
That led me to mess around with exception breakpoints to try to figure out what the issue was. In my case, I could always find the description on $eax, so I decided to add an action to the breakpoint, so I don't have to debug it each time. This caused it to always print $eax without a breakpoint, so it pretty much acts like I want it to (print the exception description, continue crashing).
Steps:
Solved the issue I was currently having, and I'm sure variations on this solution (po $ebx, po [NSThread callStackSymbols], etc) should get around most issues with missing exception descriptions.
I'm trying to debug a crash (likely memory related) but whenever the app crashes while debugging on iPad device Xcode (4.2) shows Paused with no backtrace for any thread (GDB). Switching to LLDB provides even less -- the app crashes, console shows nothing and Xcode ends debugging.
The crash only occurs after intense use and is likely related to insufficient memory.
I can't find any info related to the crash though. Anyone else experienced this behavior?
Have you set the exception breakpoint?
got to breakpoint editor pane
click on the [+] in the bottom left corner of the pane
choose add exception breakpoint
Now you should see a stacktrace if an exception occurs.
"Appearing after intensive use" indicates to excessive memory usage and memory leaks, and not that not enough memory is available.
Run the application on your device with instruments running and turn on the leaks module to find where you are not freeing allocated memory.