[zeromq-dev] Uninitialised command_t and decoder asserts

Steven McCoy steven.mccoy at miru.hk
Fri Jan 14 03:29:17 CET 2011

On 14 January 2011 09:48, Michael Small <michaelsmall at me.com> wrote:

> Hi,
> I've noticed random assertions mostly in decoder, and this seems to tie in
> with unitialised values of commant_t. While investing this I've noticed the
> following:
>    memset (&cmd, 0, sizeof (cmd));
> #endif
> Valgrind does indeed complain about these uninitialised values, and the
> randomness of the asserts (looping a REQ/REP test continually will only
> sometimes on some platforms cause the assertion even with the same library
> version).
> Is it expected that not initialising these values correctly will in fact
> cause potentially incorrect / unexpected behaviour in ZMQ?

Valgrind cannot track individual byte usage for reading from an object which
is why it gives such errors.  If you set one byte in a ten byte array and
read that one byte that is perfectly acceptable code but Valgrind will raise
an error due to the other 9 uninitialized bytes.

With the ØMQ command in particular its just a little unclear that it is
always set.

This is common practice, you can see it in GLib and plenty of other code.


I do the same with OpenPGM, in debug mode you can set
PGM_DEBUG=gc-friendlyand all memory blocks will be zeroed before use.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110114/f616a565/attachment.htm>

More information about the zeromq-dev mailing list