Open
Description
Currently I see ZeroMQ/cppzmq/libzmq hanging, after I try to exit the process.
I am using libzmq 4.2.2 on Mac OS X Sierra (10.12.6) and thought that this behaviour reflects bug described here: zeromq/libzmq#1279, wich is considered to be resolved.
I post it here because I use cppzmq bindings, but I see cppzmq to cause an abort in this line:
inline bool recv (message_t *msg_, int flags_ = 0)
{
>>> int nbytes = zmq_msg_recv (&(msg_->msg), ptr, flags_);
if (nbytes >= 0)
return true;
if (zmq_errno () == EAGAIN)
return false;
throw error_t ();
}
This is my code to shutdown the context + socket(s):
int linger_value = 0;
void* native_socket = socket_;
auto result =
zmq_setsockopt
(native_socket, ZMQ_LINGER, &linger_value, sizeof(linger_value))
;
assert(0==result);
socket_.close();
context_ptr_->close();
Closing the socket here, causes the process to abort with SIGABRT. When not calling close()
on the socket the process just hangs forever.
void* native_context = *context_ptr_;
auto result = zmq_ctx_set(native_context, ZMQ_BLOCKY, 0);
I am also not able to create non-blocking context, whenever the I call zmq_ctx_set(native_context, ZMQ_BLOCKY, 0);
I receive -1
as return value.
Activity
[-]proper context and socket shutdown[/-][+]context and socket shutdown hangs[/+]CptanPanic commentedon Nov 9, 2017
I am having the same issue. Any work around?
ovanes commentedon Nov 9, 2017
What I've found out, and that flow wasn't documented, is that one needs to unbind the endpoints from the socket first.
I ended up writing a
socket_wrapper
class having the following functionality:And finally to close everything including context I call the shutdown function (it should give you the idea of the flow...):
sigiesec commentedon Apr 4, 2018
Please provide a minimal example that reproduces the problem.
Your assumption that it is necessary to unbind sockets is not correct. However, you need to close all sockets. Context termination will block until all sockets have been closed.
kurdybacha commentedon Jun 4, 2018
@ovanes could you confirm if you still see this issue on osx, please?
mrfeod commentedon Aug 29, 2019
Hello! Does this sample has same kind of hang?
ywangtht commentedon Jan 10, 2020
Yes, above code sample has the same hang with backtrace like this:
(gdb) bt
#0 0x00007ffff6efa7e1 in poll () from /lib64/libc.so.6
#1 0x00007ffff7b8093d in zmq::signaler_t::wait(int) () from /opt/phoenix/lib64/libzmq.so.5
#2 0x00007ffff7b6789c in zmq::mailbox_t::recv(zmq::command_t*, int) () from /opt/phoenix/lib64/libzmq.so.5
#3 0x00007ffff7b59c61 in zmq::ctx_t::terminate() () from /opt/phoenix/lib64/libzmq.so.5
#4 0x00007ffff7b9b93a in zmq_ctx_term () from /opt/phoenix/lib64/libzmq.so.5
#5 0x00000000004014d1 in zmq::context_t::close (this=0x7fffffffdf28) at cppzmq/zmq.hpp:670
#6 0x00000000004014a6 in zmq::context_t::~context_t (this=0x7fffffffdf28, __in_chrg=) at cppzmq/zmq.hpp:661
#7 0x000000000040120a in main () at test1.cpp:7
NouberNou commentedon Nov 13, 2021
If it provides any context (forgive the pun), if I call
context.close()
in a class destructor where the context is a member it also hangs, despite if I call the same shutdown sequence manually before the class that the context is resident in is destroyed working fine.I guarantee all sockets are closed because they are the last actions out of all the work threads and I join all work threads before closing context. All threads join and then context close is called. If I call this stop function before the object goes out of scope and the destructor is called it works fine. If I let the destructor call then it hangs.
EDIT
I think in my situation it is because this is being loaded as a shared library and unloaded, and the unloading application is terminating threads aggressively in a way that causes the context to not shut down appropriately since it is waiting on the reaper which has been killed by the parent application.
tanish20j commentedon Jan 24, 2023
I am getting this same issue in one module of freeswitch mod_event_zmq