[zeromq-dev] Zmq 4.2.0 aligned memory

[Luca Boccassi]

On Mon, 2016-11-14 at 16:48 +0100, Emmanuel Taurel wrote:
> Hello all,
> 
> We are using zeromq since years now without troubles. We have recently
> tried our software using Zmq 4.2.0 (on linux hosts).
> For our application, we are using multipart messages with 4 parts in
> publish/subscribe mode.
> With Zmq 4.0.5, on the subscriber side, when we get the last message
> part, the received buffer was memory aligned
> (at least on 0x4 border). Unfortunately, with Zmq 4.2.0, the buffer is
> not aligned any more.
>  For instance with Zmq 4.0.5, the buffer was at address xxx08 while with
> Zmq 4.2.0, it is at address xxx23.
> 
> I don't know if it is relevant but our messages are relatively small
> messages (few tens of bytes)
> This is a problem for us in decoding the buffer content.
> 
> Is there something to be done to have memory aligned buffers?
> 
> Thank's in advance for your answers
> 
>  Emmanuel

Hi,

Since 4.0.5 a couple things have changed externally:

- zmq_msg_t has increased to 64 bytes from 32 bytes

- zmq_msg_t is now aligned to pointer size, to fix SIGBUS crashes on
some architectures

Exactly how large are your payloads?

It's possible that before they didn't fit in the inline buffer, since it
was really small, but they do now and that means they are not aligned
anymore since the inline buffer is not the first element of the struct:

struct {
   metadata_t *metadata;
   unsigned char data [max_vsm_size];
   unsigned char size;
   unsigned char type;
   unsigned char flags;
   char group [16];
   uint32_t routing_id;
} vsm;

Although an xxx23 address is a bit strange. In theory it should be
aligned to ptr size + 8.

If they are bigger than the very small size and they end up on the heap,
then the content_t is not aligned at all:

struct content_t
{
    void *data;
    size_t size;
    msg_free_fn *ffn;
    void *hint;
    zmq::atomic_counter_t refcnt;
};

You could try to add the alignment attribute there in src/msg.hpp and
see if it makes a difference for you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20161114/c169e921/attachment.sig>