[zeromq-dev] Uninitialised command_t and decoder asserts

[Steven McCoy]

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:
>
> #if defined ZMQ_MAKE_VALGRIND_HAPPY
>    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.

http://library.gnome.org/devel/glib/unstable/glib-running.html

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

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