[Spread-users] Vlagrind reports uninitialised or unaddressable byte(s) in SP_disconnect

[John Schultz]

Shlomi Yaakobovich wrote:
> Hi all, 
> 
> I ran valgrind on a client using the spread library to connect to a spread daemon, and got the following error:
> 
> ==25325== Syscall param socketcall.send(msg) contains uninitialised or unaddressable byte(s)
> ==25325==    at 0x3C66D146: send (in /lib/i686/libc-2.3.2.so)
> ==25325==    by 0x3C2B4396: SP_disconnect (sp.c:882)
> 
> It is repeatable, and happens every SP_disconnect call. I tracked down the reason, and it seems that send_group, which is declared like this: 
> 
> 	char		send_group[MAX_GROUP_NAME];
> 
> Is NOT initialized completely, only by:
> 
> 	strcpy(send_group, Sessions[ses].private_group_name );
> 
> And then it is passed to SP_internal_multicast, which uses it as is, without further modifying it:
> 
> 	memcpy( group_ptr, groups, MAX_GROUP_NAME * num_groups );
> 
> Note that the memcpy call copies the entire buffer, including the bytes after the NULL terminator, and these bytes are uninitialized. 
> 
> I am not sure this is a REAL problem, but valgrind still cries about it. It's quite easy to fix this of course, if this is indeed a problem. What do you guys think ?
> 
> Shlomi Yaakobovich
> 
> 

I'm pretty sure this is not a REAL problem.  However, all the Spread 
code should adopt a uniform way of initializing, copying and passing 
group names around.

I believe that the "right" way to do this is to zero out one past the 
last character of the name and the rest of the buffer, which is what 
most of the Spread code does.  So, that strcpy should probably be 
changed to a memcpy, or the pointer should just be passed directly.  The 
Spread daemon should ensure that these bytes are zeroed out in group 
names anyway so it doesn't actually hurt to not set them to zero in the 
client.

-- 
John Lane Schultz
Spread Concepts LLC
Phn: 443 838 2200