NativeScript / ios-jsc

NativeScript for iOS using JavaScriptCore

Home Page:http://docs.nativescript.org/runtimes/ios

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Improve crash error logs

Eonfuzz opened this issue · comments

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:

Native Stack:
1   0x107388ff1 sig_handler(int)
2   0x10bbe0f5a _sigtramp
3   0xc
4   0x10b29f865 -[NSArray initWithArray:range:copyItems:]
5   0x10c764164 _runAfterCACommitDeferredBlocks
6   0x10c752b2c _cleanUpAfterCAFlushAndRunDeferredBlocks
7   0x10c781efc _afterCACommitHandler
8   0x10b216c27 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__
9   0x10b2110be __CFRunLoopDoObservers
10  0x10b211751 __CFRunLoopRun
11  0x10b210e11 CFRunLoopRunSpecific
12  0x1123531dd GSEventRunModal
13  0x10c75881d UIApplicationMain
14  0x107d0cedd ffi_call_unix64
15  0x12dbf91e0
JS Stack:
UIApplicationMain([native code])
at _start(file:///node_modules/@nativescript/core/application/application.js:324:0)
at run(file:///node_modules/@nativescript/core/application/application.js:366:0)
at bootstrapNativeScriptApp(file:///node_modules/@nativescript/angular/platform-common.js:210:0)
at bootstrapApp(file:///node_modules/@nativescript/angular/platform-common.js:111:0)
at bootstrapModule(file:///node_modules/@nativescript/angular/platform-common.js:91:0)
at file:///app/bundle.js:9430:144
at ./app-visualiser/main.ts(file:///app/bundle.js:9435:34)
at __webpack_require__(file:///app/webpack/bootstrap:750:0)
at checkDeferredModules(file:///app/webpack/bootstrap:43:0)
at webpackJsonpCallback(file:///app/webpack/bootstrap:30:0)
at anonymous(file:///app/bundle.js:2:61)
at evaluate([native code])
at moduleEvaluation
at promiseReactionJob

And then there are times where the log becomes truncated. How is one to debug these?

NativeScript caught signal 11.
Native Stack:
1   0x103c5aff1 sig_handler(int)
2   0x108414f5a _sigtramp
3   0x7ffeec64b670
4   0x1045deedd ffi_call_unix64
5   0x13a199080
JS Stack:
addSubview([native code])
at _addViewToNativeVisualTree(file:///node_modules/@nativescript/core/ui/core/view/view.js:565:0)
at _setupUI(file:///node_modules/@nativescript/core/ui/core/view-base/view-base.js:530:0)
at file:///node_modules/@nativescript/core/ui/core/view-base/view-base.js:534:0
at eachChildView(file:///node_modules/@nativescript/core/ui/layouts/layout-base-common.js:125:0)
at eachChild(file:///node_modules/@nativescript/core/ui/core/view/view-common.js:1010:0)
at _setupUI(file:///node_modules/@nativescript/core/ui/core/view-base/view-base.js:533:0)
at file:///node_modules/@nativescript/core/ui/core/view-base/view-base.js:534:0
at eachChildView(file:///node_modules/@nativescript/core/ui/layouts/layout-base-common.js:125:0)
at eachChild(file:///node_modules/@nativescript/core/ui/core/view/view-common.js:1010:0)
at _setupUI(file:///node_modules/@nativescript/core/ui/core/view-base/view-base.js:533:0)
at file:///node_modules/@nativescript/core/ui/core/view-base/view-base.js:534:0
at eachChildView(file:///node_modules/@nativescript/core/ui/layouts/layout-base-common.js:125:0)
at eachChild(file:///node_modules/@nativescript/core/ui/core/view/view-common.js:1010:0)
at _setupUI(file:///node_modules/@nativescript/core/ui/core/view-base/view-base.js:533:0)
at _addViewCore(file:///node_modules/@nativescript/core/ui/core/view-base/view-base.js:432:0)
at _addView(file:///node_modules/@nativescript/core/ui/core/view-base/view-base.js:421:0)
at addChild(file:///node_modules/@nativescript/core/ui/layouts/layout-base-common.js:44:0)
at addChild(file:///node_modules/@nativescript/core/ui/layouts/layout-base.js:13:0)
at insertToLayout(file:///node_modules/@nativescript/angular/view-util.js:98:0)
at addToVisualTree(file:///node_modules/@nativescript/angular/view-util.js:79:0)
at insertChild(file:///node_modules/@nativescript/angular/view-util.js:41:0)
at insertBefore(file:<…>

@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.

👋 @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.