[email protected] said:
>
> On 7/9/2010, "Martin Lucina" <[email protected]> wrote:
>
> >This would seem to indicate that message has already been freed, possibly
> >by Python. However, what I'm wondering about is:
> >
> > If it fails on line 172, how did it ever get past lines 165/169?
>
> Maybe python gc have kicked in somewhere near the line 169?
Actually, this does not look like a Python issue at all. I double-checked
the pyzmq code and now that I have removed all uses of zmq.Message() from
my code, pyzmq will *always* take it's own private copy of message data
before passing it to Python (in recv) or passing it to zmq (in send).
free_fn never comes into it.
Martin, if you look at that backtrace again you'll see that ~pipe_t() is
called from zmq::reader_t::process_pipe_term_ack(). So this happens when a
pipe is in the process of being destroyed.
Now, the code in ~pipe_t() says:
// Deallocate all the unread messages in the pipe. We have to do it by
// hand because zmq_msg_t is a POD, not a class, so there's no associated
// destructor.
zmq_msg_t msg;
while (read (&msg))
zmq_msg_close (&msg);
AFAICT there should never be any pending messages on the pipe in my system
during normal operation; due to the zmq_close() issues with 2.0.9 I take
care not to close a socket unless all messages expected have been read from
it.
So what I'm seeing is that the read (&msg) in ~pipe_t () seems to be
getting back a zmq_msg_t that is all NULLs.
Any idea why this might be happening?
-mato
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
