[zeromq-dev] Fix for alignment issue of vsm_data inside zmq_msg_t message type.

Pieter Hintjens ph at imatix.com
Thu Jan 26 18:44:03 CET 2012


Rick,

Nice work!

Can I assume this affects both 2.1 and 3.1? Could you make a pull
request on the libzmq repository then? We'll backport to 2-1.

See here for contributing: http://www.zeromq.org/docs:contributing

-Pieter

On Thu, Jan 26, 2012 at 11:34 AM, Rick Flower <nrf at ca-flower.com> wrote:
> I stumbled across this issue this morning when testing out some
> new message handling code using push/pulls.  I was sending some
> small C++ classes from one thread to anther via the inproc backend.
> What I found was that the receiver would get a BUS error when trying
> to see what the packets had in them by examination of the packet
> header and calling methods on the class.  In toying around I was
> able to reproduce this issue on the sending end by calling data()
> function of the message and casting it to my custom type (which
> BTW has NO virtual functions -- just plain ol C++ data types
> and some methods -- all inlined -- no statics even).
>
> In this case my packet was only 12 bytes in size so it gets the
> built in buffer -- no allocation required.  I'm using
> zmq_msg_init_size.  So, the underlying message as a whole is
> properly aligned, but NOT the vsm_data portion once you throw
> two char's in front of it as you can see in the code below
> taken from the 2.1.11 stable build I'm using :
>
> typedef struct
> {
>     void *content;
>     unsigned char flags;
>     unsigned char vsm_size;
>     unsigned char vsm_data [ZMQ_MAX_VSM_SIZE];
> } zmq_msg_t;
>
> Now, once you move vsm_data above flags so it's right after
> content, my problem disappears since the alignment issue was
> caused by flags & vsm_size.
>
> The scenario I used to get this is more or less as follows :
>
> 1) call zmq_msg_init_size() with a buffer size of <30 to
>    get you the built-in-buffer (vsm_data from above) -- no
>    allocation required.
> 2) Create a custom C++ class (my_cool_class) with a few
>    data items and getters/setters for those items
> 3) call zmq_msg_data() and cast the pointer to a my_cool_class
>    pointer type.  Now call my_cool_class_obj->my_cool_method()
>    and watch it crash.
>
> You don't even need to send the buffer to see this.
>
> Any issues you can see?  I've already swapped the order in
> my local version of the code and rebuilt everything and it
> works great!
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



More information about the zeromq-dev mailing list