[Live-devel] Valgrind uninitialised values inside live555

[Ross Finlayson]

Not everything that ‘valgrind’ reports is actually an error.  In each case, you need to look at the code to see if there’s really an error there.


> For example I found this code inside GroupsockHelper.cpp:
> 
> 
> static Boolean getSourcePort0(int socket, portNumBits& resultPortNum/*host order*/) {
>   sockaddr_storage testAddr;
>   setPortNum(testAddr, 0);
> 
>   SOCKLEN_T len = sizeof testAddr;
>   if (getsockname(socket, (struct sockaddr*)&testAddr, &len) < 0) return False;
> 
>   resultPortNum = ntohs(portNum(testAddr));
>   return True;
> }

I’m not really sure if there’s anything really wrong here.  “getsockname()” fills in (i.e., returns) the value of “testAddr”; it doesn’t read it.  And the subsequent call to “portNum(testAddr)” shouldn't read an uninitialized value, because the port number should have been filled in by the earlier (successful) call to "getsockname()”.

What is, perhaps, strange, is the call to “setPortNum()”, which probably isn’t really needed.  And the implementation of “setPortNum()” does, indeed, rely upon the “ss_family” field, which, in this case, will be uninitialized.  So perhaps that’s what upset ‘valgrind’ here??  So I’ve gone ahead and installed a new version (2021.08.17) of the LIVE555 code that changes the implementation of "setPortNum()” to not rely upon “ss_family”.  This might make ‘valgrind’ happier in this case.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/