[zeromq-dev] Potential bug found

Martin Sustrik sustrik at 250bpm.com
Tue Aug 31 16:15:51 CEST 2010

Hi Mikael,

> I've been tinkering with my system and I've hit a problem inside zmq
> that I haven't been able to debug or figure out just yet. My code is
> trying to send when I hit it.
> I get an access violation (for those who aren't into Windows ways of
> putting things Zeromq is access memory that is not valid for it to
> use) in the zmq::writer_t::process_pipe_term() function. Apparently
> Endpoint has a value (it is not 00000000), but it is not a valid
> object because the v-table points as 0xfeeefeee which is a guard
> value if I remember correctly. Anyway zmq calls a function but the
> object no longer exists. I believe I am hitting some sort of thread
> interaction issue with zmq in the process of shutting down said
> endpoint, but the pointer to endpoint not getting cleared (always a
> possible issue if you can't use shared_ptr's and the like). Now I am
> not yet familiar with the innards of the library, but I doubt I am
> supposed to be able to crash it by calling a function on it.
> My system has the following call stack when it goes down:
> libzmqd.dll!zmq::writer_t::process_pipe_term()  Line 305 + 0x14 bytes
> C++ libzmqd.dll!zmq::object_t::process_command(zmq::command_t&
> cmd_={...})  Line 98 + 0xf bytes	C++
> libzmqd.dll!zmq::app_thread_t::process_commands(bool block_=false,
> bool throttle_=true)  Line 129	C++
> libzmqd.dll!zmq::socket_base_t::send(zmq_msg_t * msg_=0x0420f948, int
> flags_=0)  Line 351 + 0x12 bytes	C++ libzmqd.dll!zmq_send(void *
> s_=0x00d87168, zmq_msg_t * msg_=0x0420f948, int flags_=0)  Line 357
> C++ fservertest.exe!zmq::socket_t::send(zmq::message_t&  msg_={...},
> int flags_=0)  Line 246 + 0x14 bytes	C++
> All values from my side of the fence should be valid (socket_t and
> message_t mostly). The socket_t was allocated on the calling thread,
> but the context_t that it was built from was not (it was given to the
> thread as a pointer).
> I can't really pick out an easy code example to reproduce this just
> now (I have some other stuff that has priority as it is a bug in some
> production code), but I will try ASAP unless told that this is a
> known graceful shutdown issue. I will put up an issue on github if
> people think this is a zeromq bug and not just my boneheadedness.

I am looking at the code. It have changed between 2.0.8 and the trunk.

Which version are you using?


More information about the zeromq-dev mailing list