No test case since the bug only manifsets itself under concurrent load. With addition of on_disconnect triggers, iproto_session_destroy() was invoked from two places: the request handler code and iproto_session_disconnect callback. This could destroy the same session twice. Worse yet, it would be put to the session cache twice, as a free session, and then used twice for two different client sockets. This could end up in an unpredictable mess, best case: libev event loop runs infinitely since libev fd has events, while session->input.fd is already set to -1 any attempt to use the session ends up with an exception. At the same time the session in this condition can not be destroyed since it's impossible to tell libev forget about a file descriptor about which we already know nothing.
Loading
Please register or sign in to comment