sashafrey
commented
10 years ago To provoke this it is enough to call any rpcz-stub service from MAIN thread.
Example of the callstack when socket leaked:
artm_tests.exe!rpcz::connection_manager::get_frontend_socket
artm_tests.exe!rpcz::connection::send_request
artm_tests.exe!rpcz::rpc_channel_impl::call_method_full
artm_tests.exe!rpcz::rpc_channel_impl::call_method
artm_tests.exe!artm::core::NodeControllerService_Stub::CreateOrReconfigureDataLoader
artm_tests.exe!
For now workaround is not to close zmq_context (see file \src\artm\zmq_context.h)
I found a tricky problem in rpcz library. Notice that rpcz::connection_manager uses the boost::thread_Specific_ptr to allocate and deallocate ZeroMQ sockets. This is dangerous, because when new socket is allocated on MAIN thread it won't be deleted before PRCZ attempts to release the zmq::context_t. Releasing context hangs if any of sockets hasn't been closed.
class connection_manager { boost::thread_specific_ptrzmq::sockett socket; <-- thread-specific storage. };