Hi Mato, >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?
Sorry. No idea. I would have to have to reproduce the problem to check what's going on. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
