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
Server should not crash on assetion errors from the underlying library #146
Comments
👍 I tend to agree; valid server code should not crash due to invalid client behavior. In this case an error should have been emitted instead. |
oops, yep we shouldn't try to send strings/buffers of length 0. 😨 |
@reqshark this looks like a bug upstream. There's no error handling, just an always failing assertion that we can't handle. |
we should hook this up to gdb and get a back trace of the failed assertion. Maybe we can avoid passing anything to that code path if we're a sub socket. |
@nickdesaulniers as I mentioned to you earlier tonight at PeninsulaJS (which was awesome 🎉 ), I couldn't get ws transport to work with pub/sub after the libnanomsg 0.8-beta update. @aliem, I had some success using ws transport with a pub/sub on libnanomsg around 0.7-beta or thereabouts, maybe it was 0.6-beta. If you need ws://pubsub you might want to try those versions using the system flag with npm install npm install nanomsg --use_system_libnanomsg=true btw the transport is still experimental and in development, nanomsg website says dont use yet:
also @aliem if you end up trying stuff in the |
in your example code you are setting both endpoints to another thought, something maybe in addition to getting a gdb backtrace on that assertion, might have to do with what we're not exposing visa vie WS socket options at the transport layer. for example, related to #139, see usage in this test: https://github.com/nanomsg/nanomsg/blob/master/tests/ws.c#L54-L56 we're not setting anything like that before trying to send stuff (though |
I'm following the spec: The pattern itself works nicely but the client can still send messages to the server crashing it. For now I'm using it only for an internal UI, so, security does not matter in my constrained environment but it's definitely an issue for different environments. In any case it seems more an upstream issue. I'll see if I have time to reproduce the crash in plain C this weekend. |
nice job and thanks for pointing that out! your example code is correct here, my mistake about those endpoints 👍 feel free to PR other working cheers! 🍻 to following the spec! |
please reopen if this is still a problem. |
As the title. I took the ws example changing the protocol to pub/sub:
On the server:
After a ws.send('') from the client:
Now I know the client shouldn't send anything over a pub/sub socket but it should never crash the server.
The text was updated successfully, but these errors were encountered: