possible race condition on message send about simple-websocket-server

[eidheim]

Thank you. How large messages do you send, and what client are you using? Will try to reproduce this error.

[joshblum]

I'm using Chrome Version 43.0.2357.81 (64-bit).

Here is my sample code

I'm sending 650kb-75mb per message (a matrix of floats) within this loop.

[eidheim]

I have tried messages up to 2GB, both text and binary, on OS X and Debian testing, however I was unable to reproduce the error. What is the exact message Chrome displays when you get the protocol corruption (websocket-protocol I take it)?

[joshblum]

Sorry about the delay!

Client side this is the error i get:

WebSocket connection to 'ws://128.52.175.133:8080/compute/spectrogram/' failed: Invalid frame header

Server side:

Server: Error in connection 140005263548336. Error: asio.misc:2, error message: End of file

or sometimes:

Server: Closed connection 140005129325408 with status code 1002

[eidheim]

I cannot find anything wrong, either with your code nor mine. Would you mind trying with NUM_THREADS set to 1? Just to rule out threading problems. When I think about it, can your json library handle multiple threads? Is it thread safe? I know I had a similar problem with Boost.PropertyTree in https://github.com/eidheim/Simple-Web-Server/blob/master/http_examples.cpp. The solution here was to add "#define BOOST_SPIRIT_THREADSAFE" before including the json-headers (#include <boost/property_tree/ptree.hpp> and #include <boost/property_tree/json_parser.hpp>).

[joshblum]

Were you able to reproduce the error I'm seeing?

Setting NUM_THREADS to 1 still gives the error :(. and it seems that the
library is thread safe: dropbox/json11#29

Any thoughts?

On Wed, Jun 17, 2015 at 8:26 PM, Ole Christian Eidheim <
[email protected]> wrote:

I cannot find anything wrong, either with your code nor mine. Would you
mind trying with NUM_THREADS set to 1? Just to rule out threading problems.
When I think about it, can your json library handle multiple threads? Is it
thread safe? I know I had a similar problem with Boost.PropertyTree in
https://github.com/eidheim/Simple-Web-Server/blob/master/http_examples.cpp.
The solution here was to add "#define BOOST_SPIRIT_THREADSAFE" before
including the json-headers (#include and #include ).

—
Reply to this email directly or view it on GitHub
#11 (comment)
.

[eidheim]

I would try have a look at data_ss in void send_message after line 44. Print out data_ss.str() in hex or something and see if it looks correct when you get the crash. I see a similar crash in my test if I send a stream object that has data that is concurrently accessed. This should not happen, but if there is a overflow in the data that is put into the stream, I guess this can happen.

[joshblum]

cool, i'll check it out but this is progress :) is there different way to send data? (I was just following your example provided ws_examples.cpp)

[joshblum]

Ok so printing the hex is really difficult to see if there is a problem because there are so many values however I can see from the client output that the data it receives is malformed when after the server crashes (so the client may receive the first message completely, although malformed and on the next request the server crashes). This points to the data_ss buffer being concurrently modified, perhaps within the server send method, https://github.com/eidheim/Simple-WebSocket-Server/blob/master/server_ws.hpp#L137?

[joshblum]

Ok so for a temporary fix: joshblum/eeg-toolkit@e75434a

Although it would be nice if the library could support concurrent requests (or if you have pointers if my code is using any bad practices) for a more permanent fix :)

[eidheim]

I think you have a buffer overflow somewhere, and this is causing the stream to become malformed in some way. Since its working after you added the mutex, the overflow might happen in this for loop: https://github.com/joshblum/eeg-spectrogram/blob/master/ws_server.cpp#L141-L154.

[eidheim]

Closing this issue, either it was a buffer overflow (in your code), or copying of stream pointers lead to stack overflow. The latter is fixed now.