[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