[zeromq-dev] possible ZeroMQ bugs

MinRK benjaminrk at gmail.com
Tue Jan 11 08:40:17 CET 2011

On Mon, Jan 10, 2011 at 17:48, Shannon -jj Behrens <jjinux at gmail.com> wrote:

> I think I may have found a few bugs, although I have a suspicion they
> may have been covered before.  Hopefully there's I can point out at
> least one a couple new ones, though ;)
> My sample code is here: http://pastebin.com/4FC89sNc
> 1. In the code, if you replace tcp:// with
> (i.e. if your fingers accidentally type "http"
> instead of "tcp"), you don't get an error.

The error does happen normally, but it's getting swallowed by your
try...finally. Do a simple:

import zmq
ctx = zmq.Context()
s = ctx.socket(zmq.REP)

and you will get:
ZMQError: Protocol not supported

If you replace 'finally:' with:
except Exception, e:
    print e

then you won't hide all the errors.

> 2. In the code, if you replace tcp:// with
> tcp://localhost:7676, it says "No such device" which is kind of a
> mysterious error.  "Hostnames are not allowed" might be better when
> you're dealing with tcp://.

> 3. If you run the code as is, it'll hang forever in context.term().  I
> think it has to do with the fact that I have two threads.  However,
> the code is very simple, and by the type context.term() is run, one
> thread has joined with the other.  I don't see any reason why the code
> should hang.  By the way, it hangs hard--you have to kill -9 it.

It's not that you have two threads, it's that the zmq.Socket objects are
still hanging on to their references when you try to close the context.  If
you add 'del socket' or 'socket.close()' before 'context.term()', it will
exit just fine.

Does zeromq handle closing contexts with active sockets just fine?  If so,
then this is a pyzmq bug, and should be reported there (link below).

(maybe strike that last question/comment, I think Martin just answered this
part while I was typing this).

> 4. In general, the code doesn't respond well to keyboard interrupts.
> For instance, even if you comment out all the lines that start with
> thread in my code sample, hitting Cntl-C doesn't really do the right
> thing.  I've seen it fail in 3 different ways, but I've never seen it
> raise a KeyboardInterrupt and exit the program.  I'm just going to
> take a guess and say that it may be necessary to mark ZeroMQ's thread
> as a daemon thread, but I haven't looked at the code.

In many cases it does respond just fine to KeyboardInterrupts.  For
instance, stuck sends, recvs, and polls all will properly raise
KeyboardInterrupt if you give it a ctrl-C.  I'm not sure what the
explanation is for Context.term not allowing for sigint.  The method that is
stuck is ``no_sockets_sync.wait ();`` in ctx.terminate().  Is that an
interruptible method?  If so, then that's a pyzmq bug we should investigate.

> If you need me to file these anywhere, I'm happy to do that.

If you want to report python specific errors (like Python threading and
inappropriate error hiding), we invite you to post to the pyzmq Issues on
GitHub: https://www.github.com/zeromq/pyzmq/issues.


> Versions:
> Linux jjinux 2.6.35-24-generic #42-Ubuntu SMP Thu Dec 2 02:41:37 UTC
> 2010 x86_64 GNU/Linux
> zeromq-2.1.0
> pyzmq-2.1.0dev
> Thanks,
> -jj
> --
> In this life we cannot do great things. We can only do small things
> with great love. -- Mother Teresa
> http://jjinux.blogspot.com/
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110110/12169a47/attachment.htm>

More information about the zeromq-dev mailing list