Skip to content
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

Memory leak on REP socket server when the REQ client disappears #1313

Closed
topher200 opened this issue Jan 20, 2015 · 2 comments
Closed

Memory leak on REP socket server when the REQ client disappears #1313

topher200 opened this issue Jan 20, 2015 · 2 comments

Comments

@topher200
Copy link
Contributor

We're getting a memory leak on our server when we have a client make a REQ socket request but close before the server manages to send the REP socket response. The client is shut down after the server has received the request but before it has created its response. If the client does not close, the memory leak is not there.

I tracked the issue down to the message's type_t. The message is being created with type_t of type_lmsg. However, by the time it is being destroyed it is type_vsm. The type mismatch leaves the extra data found in a type_lmsg type un-destroyed.

@topher200
Copy link
Contributor Author

Created pull request #1314. This explicitly closes messages after a failed write to the socket.

Most paths through that function explicitly close the message already - the only ones that do are the ones that call zmq::pipe::write. This suggests that the author assumed that zmq::pipe::write would take control of the message's memory on every call to write. Our testing suggests that zmq::pipe::write does not take control of the message's memory buffer on a failed call. Therefore, our patch adds the needed message::close.

As the commit message says, this patch is sponsored by FarSounder, Inc.

@topher200
Copy link
Contributor Author

With the patch merged, this issue is fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant