tplgy / bonefish

C++ WAMP application router that enables building applications from loosely-coupled components.
Apache License 2.0
55 stars 33 forks source link

bad_alloc exception at websocket_server_impl.cpp:220 #8

Closed Guitlle closed 9 years ago

Guitlle commented 9 years ago

I'm running bonefish in a docker container. When I try this simple javascript, I get this on bonefish:

<!DOCTYPE html>
<html>
   <body>
      <script
         src="https://autobahn.s3.amazonaws.com/autobahnjs/latest/autobahn.min.jgz">
      </script>
      <script>
var connection = new autobahn.Connection({
   url: "ws://localhost:9999",
   realm: "default"
});
connection.onopen = function (session, details) {
    console.log(session, details);
};

connection.onclose = function (reason, details) {
   console.log("Connection lost: " + reason);
}

// Open connection
connection.open();
        </script>
   </body>
</html>
[websocket_server_impl.cpp:53][start] starting websocket server: 0.0.0.0:9999
[2015-08-28 23:58:43] [connect] WebSocket Connection 172.17.42.1:40386 v13 "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.130 Safari/537.36" / 101
[websocket_server_impl.cpp:220][on_message] unhandled exception: std::bad_alloc

After I close the browser tab it says this:

[2015-08-29 00:02:27] [control] Control frame received with opcode 8
[2015-08-29 00:02:27] [frame_header] Dispatching write containing 1 message(s) containing 2 header bytes and 2 payload bytes
[2015-08-29 00:02:27] [frame_header] Header Bytes: 
[0] (2) 88 02 

[2015-08-29 00:02:27] [frame_payload] Payload Bytes: 
[0] (2) [8] 03 E9 

[2015-08-29 00:02:27] [disconnect] Disconnect close local:[1001] remote:[1001]

The dockerfile is here, so hopefully it is easily reproducible: https://gist.github.com/DuGuille/1eca9a127ca281aa0ea9

jpetso commented 9 years ago

I debugged it a bit and the problem is in the JSON deserializer. I found one bug where it mistakenly puts an object into m_queues in msgpack_from_json_handler::Int()/Int64(), and then another one from Uint64() to which it redirects. That's one too many, so I fixed that bug locally. However, it doesn't seem to change anything for this particular use case apparently.

m_queues has 5 objects in the queue when it gets back to the last EndObject(), and I presume there should be less (like 2 or so). Looking through the code, I don't really see where the extra objects would come from. So I guess it's more debugging. Not sure if I'll do this tonight still.

jpetso commented 9 years ago

@efidler helped out with some more debugging and we found that the issue is with m_queued being resized and m_containers still containing a pointer to an old m_queued item (before it was moved to a bigger array). I'm working on a patch.

Thanks for the awesome test case, by the way. It's really helpful :)