-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
Crashes when UDP/dgram socket is closed during listening event handler #7061
Labels
confirmed-bug
Issues with confirmed bugs.
dgram
Issues and PRs related to the dgram subsystem / UDP.
Comments
cc @mcollina |
Thanks for reporting. It is a bug, as the sendQueue is not flushed out before calling |
mcollina
added a commit
to mcollina/node
that referenced
this issue
May 30, 2016
If the udp socket is not ready and we are accumulating messages to send, it needs to delay closing the socket when all messages are flushed. Fixes: nodejs#7061
3 tasks
mcollina
added a commit
to mcollina/node
that referenced
this issue
Nov 19, 2016
If the udp socket is not ready and we are accumulating messages to send, it needs to delay closing the socket when all messages are flushed. Fixes: nodejs#7061 PR-URL: nodejs#7066 Reviewed-By: Anna Henningsen <anna@addaleax.net>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
confirmed-bug
Issues with confirmed bugs.
dgram
Issues and PRs related to the dgram subsystem / UDP.
Node.js crashes when a UDP/dgram socket is closed in the
listening
event handler.Output / Stack trace using node.js 4.3:
This seems to happen because node.js attaches an own eventhandler to the
listening
event which will try to send messages that were enqueued before, but have not been sent (https://github.com/nodejs/node/blob/master/lib/dgram.js#L288-L293). This closure might run after a user event handler which might close the socket (like mine does if it fails to join a multicast group). When it runs and tries to send messages on the already closed socket an exception is thrown which can not be captured by the user, because it's not on his callstack.What should be done to avoid that:
listening
handler should check if the socket is still open before starting to send enqueued messages and should simply return if it's no longer open.close()
function should flush the sendQueue, which would also avoid that the handler does attempt to send anything.Actually the second part is more part, because it seems that currently the callbacks for those queued sends are also never called if the socket is closed before connecting and because it would already solve the issue. However another sanity check in the
listening
handler would still be ok.Workarounds:
listening
handler, but defer the custom logic in a new eventloop tick.My code for reproduction:
The text was updated successfully, but these errors were encountered: