[zeromq-dev] Poll Reactor Issue.

Riskybiz riskybizlive at live.com
Tue Nov 4 12:51:57 CET 2014


I’m creating a zeromq poll reactor with Visual Studio Express 2013 on Windows 7 64bit and working in Visual C++ using zeromq-4.0.4.

 

The intent is an easily configurable object oriented piece of code to allow any number of user specified zeromq sockets to be polled and corresponding user defined functors to be called on relevant ZMQ_POLLIN and ZMQ_POLLOUT events. 

 

Trouble is I am experiencing an inexplicable issue.  I have found that when run in the Visual Studio ‘Local Windows Debugger’ with either ‘release’ or ‘debug’ selected then my poll reactor examples; reactorServer.exe and reactorClient.exe will FUNCTION AS INTENDED and happily pass messages back and forth over a DEALER and ROUTER  connection.  Sending and receiving in both directions.

 

HOWEVER when I open an ordinary console window and run the server program it begins to poll, but IMMEDIATELY that a client is connected (the client would be trying to send messages to the ROUTER socket of the server and the server would presumably be detecting a ZMQ_POLLIN event) then the server program crashes.  I reiterate that when run in the debugger the server and client play nicely.

 

After starting the ‘release’ version of my reactorServer.exe in an ordinary console window I attach that process to the Visual Studio debugger. I then deliberately crash the server by starting a reactorClient.exe.  I get the following error reported by the debugger:

 

Unhandled exception at 0x54093B2C (libzmq.dll) in reactorServer.exe: 0xC0000005: Access violation reading location 0x00000068.

 

Following through shows the server program crashed at this function in file ctx.cpp.

 

zmq::io_thread_t *zmq::ctx_t::choose_io_thread (uint64_t affinity_)

{

    if (io_threads.empty ())

        return NULL;

 

    //  Find the I/O thread with minimum load.

    int min_load = -1;

    io_thread_t *selected_io_thread = NULL;

    for (io_threads_t::size_type i = 0; i != io_threads.size (); i++) {

        if (!affinity_ || (affinity_ & (uint64_t (1) << i))) {

>>>>>>int load = io_threads [i]->get_load ();<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Crashes here.  This is the next statement to execute. 

            if (selected_io_thread == NULL || load < min_load) {

                min_load = load;

                selected_io_thread = io_threads [i];

            }

        }

    }

    return selected_io_thread;

}

 

The call stack shows:

 

>        libzmq.dll!zmq::ctx_t::choose_io_thread(unsigned __int64 affinity_) Line 339        C++

        libzmq.dll!zmq::tcp_listener_t::in_event() Line 100        C++

        libzmq.dll!zmq::select_t::loop() Line 185        C++

        libzmq.dll!thread_routine(void * arg_) Line 35        C++

        msvcr120.dll!_callthreadstartex() Line 376        C

        msvcr120.dll!_threadstartex(void * ptd) Line 354        C

        kernel32.dll!@BaseThreadInitThunk at 12‑()        Unknown

        ntdll.dll!___RtlUserThreadStart at 8‑()        Unknown

        ntdll.dll!__RtlUserThreadStart at 8‑()        Unknown

 

 

 I simply would like to ask if this offers a clue to someone familiar with the zeromq source code as to the likely problem?  It could be my application code! But equally have I encountered some issue not of my making?

 

Thanks,

 

Riskybiz.

 

P.S. Also built against zeromq-3.2.3 and found the same behaviour.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20141104/4dc53f88/attachment.htm>


More information about the zeromq-dev mailing list