jhs67 / usocket

node unix domain sockets
ISC License
12 stars 7 forks source link

Segfault on Node13&14 #7

Closed allie47 closed 3 years ago

allie47 commented 3 years ago

Seems that on Node 13 & Node 14, there is some issue in usocket, as it does cause a segfault occasionally.

usocket version: 0.2.1 OS: Linux (Debian, but replicated also on other distributions) Activity performed: When connecting and destroying the connection repeatedly (repeated logging in and out of an application, fast). There does not seem to be a clear pattern in when it happens (number of repeats to get the issue nor point in code that the issue would clearly happen on).

Tested Node versions:

Output I got from segfault-handler for Node14.15.4:

PID 1469 received SIGSEGV for address: 0x3c0
[path-to-my-project]/node_modules/segfault-handler/build/Release/segfault-handler.node(+0x3216)[0x7f9dbaa76216]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7f9dba734730]
node(_ZN4node9AsyncWrap11EmitDestroyEPNS_11EnvironmentEd+0xd)[0x97990d]
node(_ZN4node16EmitAsyncDestroyEPN2v87IsolateENS_13async_contextE+0x77)[0x971737]
[path-to-my-project]/node_modules/usocket/build/Release/uwrap.node(_ZN5uwrap11USocketWrapD0Ev+0xe0)[0x7f9db854c910]
node(_ZN2v88internal13GlobalHandles28InvokeFirstPassWeakCallbacksEv+0xdf)[0xcf658f]
node(_ZN2v88internal4Heap14CollectGarbageENS0_15AllocationSpaceENS0_23GarbageCollectionReasonENS_15GCCallbackFlagsE+0x5e8)[0xd42f28]
node(_ZN2v88internal4Heap34AllocateRawWithRetryOrFailSlowPathEiNS0_14AllocationTypeENS0_16AllocationOriginENS0_19AllocationAlignmentE+0x5c)[0xd46b9c]
node(_ZN2v88internal7Factory15NewFillerObjectEibNS0_14AllocationTypeENS0_16AllocationOriginE+0x2b)[0xd1527b]
node(_ZN2v88internal33Runtime_AllocateInYoungGenerationEiPmPNS0_7IsolateE+0x9f)[0x105b21f]
node[0x14011f9]

Output I got from segfault-handler for Node13.14.0:

PID 19895 received SIGSEGV for address: 0x630
[path-to-my-project]/node_modules/segfault-handler/build/Release/segfault-handler.node(+0x3216)[0x7f70f613b216]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7f70f5df9730]
node(_ZN4node9AsyncWrap11EmitDestroyEPNS_11EnvironmentEd+0x9)[0x98cf59]
node(_ZN4node16EmitAsyncDestroyEPN2v87IsolateENS_13async_contextE+0x77)[0x984a27]
[path-to-my-project]/node_modules/usocket/build/Release/uwrap.node(_ZN5uwrap11USocketWrapD0Ev+0xe0)[0x7f70f4412930]
node(_ZN2v88internal13GlobalHandles28InvokeFirstPassWeakCallbacksEv+0xfa)[0xcfbeea]
node(_ZN2v88internal4Heap24PerformGarbageCollectionENS0_16GarbageCollectorENS_15GCCallbackFlagsE+0x1e9)[0xd41129]
node(_ZN2v88internal4Heap14CollectGarbageENS0_15AllocationSpaceENS0_23GarbageCollectionReasonENS_15GCCallbackFlagsE+0x215)[0xd42045]
node(_ZN2v88internal4Heap34AllocateRawWithRetryOrFailSlowPathEiNS0_14AllocationTypeENS0_16AllocationOriginENS0_19AllocationAlignmentE+0x4c)[0xd44b1c]
node(_ZN2v88internal7Factory15NewFillerObjectEibNS0_14AllocationTypeENS0_16AllocationOriginE+0x34)[0xd0b6f4]
node(_ZN2v88internal33Runtime_AllocateInYoungGenerationEiPmPNS0_7IsolateE+0x9e)[0x105790e]
node[0x13da519]
jhs67 commented 3 years ago

Thanks for your report.

Looks like both crashes are during the garbage collection, so that at least gives me a little something to go on.

jhs67 commented 3 years ago

@allie47 Sorry for the delay. I've pushed up some changes that I hope will resolve the issue you are having. Do you have the ability to test them before I create a release?

allie47 commented 3 years ago

@jhs67 I can try to look into it tomorrow - whether I can realistically test it without a release.

allie47 commented 3 years ago

@jhs67 Alright, checked it out, seems that it no longer causes SegFault, so yes, it does resolve the issue.

Edit: Originally I experienced some warnings in gyp-rebuild, but it turned out that was a different cause. So removed that part of this comment.

jhs67 commented 3 years ago

Awesome, thank you. I'll create a release today.