[zeromq-dev] [zmqpp] [libzmq] Wrapping zmq messages

[Lindley French]

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 <lindleyf at 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:
>
> vector<mutable_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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140109/fec9a87e/attachment.htm>