Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TLSSocket.onHangUp produces fatal error #8

Closed
jlsjonas opened this issue Apr 19, 2016 · 4 comments
Closed

TLSSocket.onHangUp produces fatal error #8

jlsjonas opened this issue Apr 19, 2016 · 4 comments

Comments

@jlsjonas
Copy link

similar to my comments on #6, however:
restarting log stash service causes (expected) disconnect, AND an "unhandled" socket hang up,
I've used longjohn to help trace the issue and sourced the (possible) root of the problem to ClientSocket and/or Client

This error breaks the log queue during disconnect, since it just takes the whole app with it.

trace (invoked by restarting the log stash service):

WARN : Disconnected undefined
WARN : Disconnected undefined
Error: socket hang up
    at TLSSocket.onHangUp (_tls_wrap.js:1089:19)
    at emitNone (events.js:85:20)
    at TLSSocket.emit (events.js:179:7)
    at endReadableNT (_stream_readable.js:906:12)
    at nextTickCallbackWith2Args (node.js:475:9)
    at process._tickCallback (node.js:389:17)
---------------------------------------------
    at fireErrorCallbacks (net.js:446:15)
    at TLSSocket.Socket._destroy (net.js:453:5)
    at TLSSocket.Socket.destroy (net.js:497:8)
    at TLSSocket.onHangUp (_tls_wrap.js:1091:14)
    at emitNone (events.js:85:20)
    at TLSSocket.emit (events.js:179:7)
    at endReadableNT (_stream_readable.js:906:12)
    at nextTickCallbackWith2Args (node.js:475:9)
    at process._tickCallback (node.js:389:17)
---------------------------------------------
    at Object.TLSSocket._init.ssl.onclienthello.ssl.oncertcb.exports.connect (_tls_wrap.js:1094:10)
    at ClientSocket.connect (/Users/jonas/Documents/Webstorm/counterluckEngine/node_modules/lumberjack-protocol/lib/ClientSocket.js:54:26)
    at Client._connect (/Users/jonas/Documents/Webstorm/counterluckEngine/node_modules/lumberjack-protocol/lib/Client.js:82:22)
    at [object Object].<anonymous> (/Users/jonas/Documents/Webstorm/counterluckEngine/node_modules/lumberjack-protocol/lib/Client.js:118:26)
    at Timer.listOnTimeout (timers.js:92:15)
---------------------------------------------
    at Client._disconnect (/Users/jonas/Documents/Webstorm/counterluckEngine/node_modules/lumberjack-protocol/lib/Client.js:115:37)
    at ClientSocket.<anonymous> (/Users/jonas/Documents/Webstorm/counterluckEngine/node_modules/lumberjack-protocol/lib/Client.js:4:59)
    at emitNone (events.js:80:13)
    at ClientSocket.emit (events.js:179:7)
    at ClientSocket._disconnect (/Users/jonas/Documents/Webstorm/counterluckEngine/node_modules/lumberjack-protocol/lib/ClientSocket.js:80:14)
    at ClientSocket._disconnect (/Users/jonas/Documents/Webstorm/counterluckEngine/node_modules/lumberjack-protocol/lib/ClientSocket.js:4:59)
    at TLSSocket.<anonymous> (/Users/jonas/Documents/Webstorm/counterluckEngine/node_modules/lumberjack-protocol/lib/ClientSocket.js:66:24)
    at emitNone (events.js:85:20)
    at TLSSocket.emit (events.js:179:7)
    at endReadableNT (_stream_readable.js:906:12)
    at nextTickCallbackWith2Args (node.js:475:9)
    at process._tickCallback (node.js:389:17)
@jwalton
Copy link
Contributor

jwalton commented Dec 14, 2016

So, TLSSocket emits an event (probably "error"), and we end up in ClientSocket._disconnect() (from one of these two). As we make our way up the chain, we end up in ClientSocket.connect, which calls into TLS's `connect()' here. And somehow this is producing an unhandled error, even though we handle the error here. O_o

@jwalton
Copy link
Contributor

jwalton commented Dec 14, 2016

Ok, this was kind of an obnoxious error. The problem (and fix) is here.

Basically, I was trying to be aggressive about garbage collection - removing all the listeners (which have references to the ClientSocket by way of closures), and setting @_socket to null. The problem here was, one of these sockets was continuing to emit errors after we'd removed all the listeners and discarded the socket, which is how we were running into this problem.

It's a little bit worrisome that this socket, which should be dead at this point, continues to push errors. Hopefully we're not leaking sockets. -_-

@jwalton
Copy link
Contributor

jwalton commented Dec 14, 2016

Fixed in [email protected] (and I updated the dependency in [email protected].)

@jwalton jwalton closed this as completed Dec 14, 2016
@jwalton
Copy link
Contributor

jwalton commented Jan 5, 2017

🤦‍♂️ Fixed even better in 1.0.6: f32cc4a

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants