Closed Eonfuzz closed 4 years ago
@Eonfuzz signal 11 is also called SIGSEGV or segmentation fault. They are usually caused by some memory mismanagement earlier in the execution and are quite hard to track down. To quote from Apple's article on analyzing crash dumps:
Bad Memory Access [EXC_BAD_ACCESS // SIGSEGV // SIGBUS]
The process attempted to access invalid memory, or it attempted to access memory in a manner not allowed by the memory's protection level (e.g. writing to read-only memory). The Exception Subtype field contains a kern_return_t describing error and the address of the memory that was incorrectly accessed.
Here are some tips for debugging a bad memory access crash:
If objc_msgSend or objc_release are near the top of the Backtraces for the crashed thread, the process may have attempted to message a deallocated object. You should profile the application with the Zombies instrument to better understand the conditions of this crash.
If gpus_ReturnNotPermittedKillClient is near the top of the Backtraces for the crashed thread, the process was killed because it attempted to do rendering with OpenGL ES or Metal while in the background. See QA1766: How to fix OpenGL ES application crashes when moving to the background.
Run your application with the Address Sanitizer enabled. The address sanitizer adds additional instrumentation around memory access in your compiled code. As your application runs, Xcode will alert you if memory is accessed in a way that could lead to a crash.
I strongly recommend using Address Sanitizer as a first step to understanding what may be causing such issues. Here's another article that you might find useful: Address Sanitizer - Track down memory violations in your code. To activate it, you can follow the instructions at Enabling the Address Sanitizer
Regarding the truncations, I suggest that you debug your app from Xcode or use the Console App. In both places, the messages should be fully visible.
In order to have symbolicated native callstacks you can download the .dSYM
bundle archive of the iOS Runtime version that your app uses from here: https://github.com/NativeScript/ios-runtime/releases. All you need to do is download and extract the .dSYM.zip
archive somewhere on your local disk and Xcode should be able to pick it up from there and start showing you more accurate call stacks.
:wave: @Eonfuzz, we use the issue tracker exclusively for bug reports and feature requests. However, this issue appears to be a support request. Please, use Stackoverflow to get help.
Currently I'm fighting a Signal 11 error and am confounded how I am meant to work out the source of the error.
Here's the only log I am getting:
And then there are times where the log becomes truncated. How is one to debug these?