Re: [Nmh-workers] [exmh-workers] Second release candidate for nmh1.5 is now available

[David Levine]

Ken wrote:

> Looking at this ...
>
> >==24349== Syscall param socketcall.send(msg) points to
> uninitialised byte(s)
> >==24349==    at 0x41106A1: send (in /lib/i686/libc-2.4.so)
> >==24349==    by 0x41401F6: (within /lib/i686/libc-2.4.so)
> >==24349==    by 0x413E0D3: (within /lib/i686/libc-2.4.so)
> >==24349==    by 0x413E3F7: (within /lib/i686/libc-2.4.so)
> >==24349==    by 0x40D05F6: getpwuid_r (in
> /lib/i686/libc-2.4.so)
> >==24349==    by 0x40CFEE7: getpwuid (in /lib/i686/libc-2.4.so)
> >==24349==    by 0x8056000: getuserinfo (mts.c:368)
> >==24349==    by 0x8056160: getusername (mts.c:308)
> >==24349==    by 0x8059A4B: ismymbox (addrsbr.c:331)
> >==24349==    by 0x80520DF: do_name (fmt_compile.c:507)
> >==24349==    by 0x8052708: do_func (fmt_compile.c:564)
> >==24349==    by 0x805249D: do_if (fmt_compile.c:713)
> >==24349==  Address 0xBEE62F43 is on thread 1's stack
> >FAIL: test/inc/test-deb359167
>
> It looks like valgrind is complaining about something deep within the C
> library, specifically getpwuid().  I don't think this is our fault.

Yup.  I noticed this on CentOS 5.4, also old.  I just added
a note about it to the make check section of INSTALL.

David