After much head-banging, valgrinding, I've finally identified the problem.
Since msg stores the zmq_msg_t objects in a vector, and small enough
messages are stored directly in the zmq_msg_t rather than by pointer,
calling raw_new_msg() was actually invalidating some of the pointers I have
previously obtained from zmq_msg_data().
I was able to solve the problem by moving the emplace_back() to a separate
loop.
On Wed, Jan 8, 2014 at 4:44 PM, Lindley French lindl...@gmail.com wrote:
Until we get UDP up and running in 0MQ, I'm using Boost.Asio for my UDP
needs. However, my API uses zmqpp::message_t types, so I need to convert
between these. This is easy enough when sending, since a
boost::asio::buffer only needs a pointer and a size and these can be
obtained from zmq message parts easily enough.
On the receiving side, it's less clear to me what to do. zmqpp::message_t
doesn't provide a way to add an uninitalized message part of a specified
size (IMO, raw_new_msg ought to take a size parameter with a default of 0),
and libzmq doesn't provide a simple way to resize and initialized message,
so I'm doing this:
vectormutable_buffer buffers; // ASIO scatter buffers
buffers.reserve(nparts);
// I've determined the number of zmq message parts to expect previously
for (size_t i = 0; i nparts; ++i)
{
zmq_msg_t inplace = msg.raw_new_msg();
{
zmq_msg_t newpart;
zmq_msg_init_size(newpart,sizes[i+1]);
zmq_msg_move(inplace,newpart);
zmq_msg_close(newpart);
}
buffers.emplace_back(zmq_msg_data(inplace),
zmq_msg_size(inplace));
}
asio_udp.receive(buffers);
However, I'm getting memory faults and I suspect this logic is to blame.
Anyone see any problems with it?
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
