Segmentation fault on manual/testapp.js periodically

[trevorlinton]

This is an intermintent issue, sometimes it will, sometimes it wont. Possibly due to node's event loop not integrated into the application callback. However curious if this could be possibly a V8 GC issue, looking to create a more automated unit test of the failure (that's statistically relevant or predictable).

[trevorlinton]

Trevors-MacBook-Pro-2:manual tlinton$ node testapp.js
Segmentation fault: 11
Trevors-MacBook-Pro-2:manual tlinton$ node testapp.js
Segmentation fault: 11
Trevors-MacBook-Pro-2:manual tlinton$ node testapp.js
got applicationDidFinishLauching
NSConcreteNotification 0x100b37ca0 {name = NSApplicationDidFinishLaunchingNotification; object = <NSApplication: 0x100c1d730>; userInfo = {
    NSApplicationLaunchIsDefaultLaunchKey = 1;
}}
Trevors-MacBook-Pro-2:manual tlinton$ node testapp.js
Segmentation fault: 11
Trevors-MacBook-Pro-2:manual tlinton$ node testapp.js
Segmentation fault: 11
Trevors-MacBook-Pro-2:manual tlinton$ node testapp.js
got applicationDidFinishLauching
NSConcreteNotification 0x100c3e5d0 {name = NSApplicationDidFinishLaunchingNotification; object = <NSApplication: 0x100b19fe0>; userInfo = {
    NSApplicationLaunchIsDefaultLaunchKey = 1;
}}
Trevors-MacBook-Pro-2:manual tlinton$ 

Refer to above log

[TooTallNate]

An lldb (or gdb if you're using a node compiled via gcc) backtrace is probably the next step.

[trevorlinton]

Interesting, in a debug mode of node it just emits a javascript error that the class cannot be allocated.

[trevorlinton]

Note to self, Xcode injects some application shims unwittingly, using lldb I got:

(lldb) run
Process 34301 launched: '/usr/local/bin/node' (x86_64)
className: AppDelegate class pointer: 140735126343920
className: RedRectView class pointer: 140735147490488
Process 34301 stopped
* thread #1: tid = 0xd0261, 0x00007fff886f45d7 libobjc.A.dylib`object_getClass + 28, queue = 'com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=1, address=0x13c)
    frame #0: 0x00007fff886f45d7 libobjc.A.dylib`object_getClass + 28
libobjc.A.dylib`object_getClass + 28:
-> 0x7fff886f45d7:  movq   (%rdi), %rax
   0x7fff886f45da:  ret    
   0x7fff886f45db:  nop    
   0x7fff886f45dc:  nop    
(lldb) bt
error: unable to find CIE at 0x00000018 for cie_id = 0x00000004 for entry at 0x00000018.
error: unable to find CIE at 0x00000050 for cie_id = 0x00000004 for entry at 0x00000050.
* thread #1: tid = 0xd0261, 0x00007fff886f45d7 libobjc.A.dylib`object_getClass + 28, queue = 'com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=1, address=0x13c)
    frame #0: 0x00007fff886f45d7 libobjc.A.dylib`object_getClass + 28
    frame #1: 0x0000000100e92f44 ffi_bindings.node`ffi_call_unix64 + 76 at darwin64.S:75
    frame #2: 0x0000000100e92895 ffi_bindings.node`ffi_call(cif=<unavailable>, fn=0x00007fff886f45bb, rvalue=<unavailable>, avalue=0x0000000101017478) + 705 at ffi64.c:492
    frame #3: 0x0000000100e8e6fa ffi_bindings.node`FFI::FFICall(args=<unavailable>) + 310 at ffi.cc:277
    frame #4: 0x00000001001710ac node`v8::internal::Builtin_HandleApiCall(v8::internal::(anonymous namespace)::BuiltinArguments<(v8::internal::BuiltinExtraArguments)1>, v8::internal::Isolate*) + 460
    frame #5: 0x000033d462206362
    frame #6: 0x000033d4622a7466
    frame #7: 0x000033d46220ccce
    frame #8: 0x000033d462647345
    frame #9: 0x000033d46220ccce
    frame #10: 0x000033d46220d1e4
    frame #11: 0x000033d46263bdee
    frame #12: 0x000033d46263b8dd
    frame #13: 0x000033d46270c900
    frame #14: 0x000033d46270c791
    frame #15: 0x000033d46220ccce
    frame #16: 0x000033d4622122d8
    frame #17: 0x000033d46270c1a1
    frame #18: 0x000033d46220d507
    frame #19: 0x000033d462206116
    frame #20: 0x000000010019f0a7 node`v8::internal::Invoke(bool, v8::internal::Handle<v8::internal::JSFunction>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*, bool*) + 439
    frame #21: 0x000000010014b0b8 node`v8::Function::Call(v8::Handle<v8::Object>, int, v8::Handle<v8::Value>*) + 440
    frame #22: 0x0000000100e8ed32 ffi_bindings.node`CallbackInfo::DispatchToV8(info=<unavailable>, retval=<unavailable>, parameters=<unavailable>, direct=true) + 150 at callback_info.cc:51
    frame #23: 0x0000000100e8f083 ffi_bindings.node`CallbackInfo::Invoke(cif=<unavailable>, retval=0x00007fff5fbfd800, parameters=0x00007fff5fbfd680, user_data=0x0000000103dfc068) + 67 at callback_info.cc:144
    frame #24: 0x0000000100e92bc7 ffi_bindings.node`ffi_closure_unix64_inner(closure=<unavailable>, rvalue=0x00007fff5fbfd800, reg_args=<unavailable>, argp=0x00007fff5fbfd820) + 662 at ffi64.c:637
    frame #25: 0x0000000100e930c6 ffi_bindings.node`ffi_closure_unix64 + 70 at darwin64.S:223
    frame #26: 0x00007fff8fb8a718 AppKit`-[NSView _drawRect:clip:] + 4253
    frame #27: 0x00007fff8fb88d79 AppKit`-[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1875
    frame #28: 0x00007fff8fb8917d AppKit`-[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 2903
    frame #29: 0x00007fff8fb8917d AppKit`-[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 2903
    frame #30: 0x00007fff8fb86c05 AppKit`-[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 913
    frame #31: 0x00007fff8fb8636c AppKit`-[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 333
    frame #32: 0x00007fff8fb82eaa AppKit`-[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 2761
    frame #33: 0x00007fff8fb61e78 AppKit`-[NSView displayIfNeeded] + 1876
    frame #34: 0x00007fff8fb7edd5 AppKit`-[NSWindow displayIfNeeded] + 232
    frame #35: 0x00007fff8fb7bf90 AppKit`-[NSWindow _reallyDoOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 1994
    frame #36: 0x00007fff8fb7b519 AppKit`-[NSWindow _doOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 799
    frame #37: 0x00007fff8fb7b194 AppKit`-[NSWindow orderWindow:relativeTo:] + 159
    frame #38: 0x00007fff8fb6c0eb AppKit`-[NSWindow makeKeyAndOrderFront:] + 47
    frame #39: 0x0000000100e92f44 ffi_bindings.node`ffi_call_unix64 + 76 at darwin64.S:75
    frame #40: 0x0000000100e92895 ffi_bindings.node`ffi_call(cif=<unavailable>, fn=0x00007fff886ed0c0, rvalue=<unavailable>, avalue=0x00000001010173c0) + 705 at ffi64.c:492
    frame #41: 0x0000000100e8e6fa ffi_bindings.node`FFI::FFICall(args=<unavailable>) + 310 at ffi.cc:277
    frame #42: 0x00000001001710ac node`v8::internal::Builtin_HandleApiCall(v8::internal::(anonymous namespace)::BuiltinArguments<(v8::internal::BuiltinExtraArguments)1>, v8::internal::Isolate*) + 460
    frame #43: 0x000033d462206362
    frame #44: 0x000033d4622a7466
    frame #45: 0x000033d46220ccce
    frame #46: 0x000033d4622122d8
    frame #47: 0x000033d46264584b
    frame #48: 0x000033d46220ccce
    frame #49: 0x000033d4622122d8
    frame #50: 0x000033d46264c7fa
    frame #51: 0x000033d46263fd0a
    frame #52: 0x000033d46220ccce
    frame #53: 0x000033d4622652ad
    frame #54: 0x000033d4622122de
    frame #55: 0x000033d462263ff0
    frame #56: 0x000033d46225ee65
    frame #57: 0x000033d46225af76
    frame #58: 0x000033d46224a387
    frame #59: 0x000033d462249d4b
    frame #60: 0x000033d46222e259
    frame #61: 0x000033d46222d7e5
    frame #62: 0x000033d46220d507
    frame #63: 0x000033d462206116
    frame #64: 0x000000010019f0a7 node`v8::internal::Invoke(bool, v8::internal::Handle<v8::internal::JSFunction>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*, bool*) + 439
    frame #65: 0x000000010014b0b8 node`v8::Function::Call(v8::Handle<v8::Object>, int, v8::Handle<v8::Value>*) + 440
    frame #66: 0x000000010000989f node`node::Load(v8::Handle<v8::Object>) + 280
    frame #67: 0x000000010000a39e node`node::Start(int, char**) + 304
    frame #68: 0x00000001000015b4 node`start + 52
(lldb) 

[trevorlinton]

@TooTallNate Thoughts? See below.

So, this happens on the callback of drawRect: in testapp.js here:

RedRectView.addInstanceMethod('drawRect:', 'v@:@', function (self, _cmd, rect) {

it expects a NSRect back, but sometimes gets a pointer on teh heap, and other times seems to get a passed back value (that's inconsistant, at times its 0x842, or 0x491, or any three digit hexadecimal number). Obviously the type signature for the callback should be more specific to specify a NSRect structure but its probably going to be a fairly common issue for users to specify @ instead of an encoded struct type, in addition i'm concerned that sometimes, it works! and other times, it fails.

See below:

Trevors-MacBook-Pro-2:manual tlinton$ node testapp.js
calling:  function (self, _cmd, rect) {
    //console.log(self);
    ObjC.NSColor('redColor')('set');
    ObjC.NSRectFill(ObjC.NSMakeRect(0,0,100,100));
    //self.super('drawRect',rect);
    //RedRectView.getSuperclass()('drawRect', self);
}  arguments:  { '0': <SlowBuffer@0x103a12600 >,
  '1': <SlowBuffer@0x7fff9039c39b >,
  '2': <SlowBuffer@0x491 > } and argTypes:  [ '@', ':', '@' ]
calling:  function (self, _cmd, notif) {
    console.log('got applicationDidFinishLauching');
    console.log(notif);
}  arguments:  { '0': <SlowBuffer@0x103a10ad0 >,
  '1': <SlowBuffer@0x7fff8f3c83a9 >,
  '2': <SlowBuffer@0x100c51770 > } and argTypes:  [ '@', ':', '@' ]
got applicationDidFinishLauching
NSConcreteNotification 0x100c51770 {name = NSApplicationDidFinishLaunchingNotification; object = <NSApplication: 0x103a08510>; userInfo = {
    NSApplicationLaunchIsDefaultLaunchKey = 1;
}}
^CTrevors-MacBook-Pro-2:manual tlinton$ 

[trevorlinton]

Alright, it seems the reason it fails or succeeds is the passed nsrect sometimes passes being read and other times it fails, that's actually not the issue. The issue seems to purely be the fact that a structure is being passed back as a object ID. Working on a few approaches to make it more obvious that the wrong type was passed into a delegate.

@tootallnate do you know of a war to potentially determine if the passed back pointer is a class, an id or struct vs a primitive using objc runtime? Using get class or anything else seems potentially seg fault

[trevorlinton]

https://github.com/TooTallNate/NodObjC/pull/43 fixes this.

[trevorlinton]

Merged