Re: [Valgrind-developers] valgrind: r6640 - trunk/memcheck

[Julian S. <js...@ac...>]

On Sunday 11 March 2007 13:58, Dirk Mueller wrote:
> On Sunday, 11. March 2007, sv...@va... wrote:
> > It appears glibc-2.5's getenv() function steps along environment
> > strings in 16-bit chunks, which can cause false errors
>
> Are you sure that they're false?

Well, um, err, not sure.  Good question.  I found this when running a
complete KDE session on V (openSUSE 10.2, amd64) and got loads of errors 
from getenv().  I added the replacement function and the noise went 
away, so it's not KDE that was causing it, which was my immediate
concern.

Whether glibc's getenv() is broken, or just optimised too much for
memcheck, I don't know.  Now you mention it, maybe there is something
bad going on.  At the start of glibc-2.5/stdlib/getenv.c is this:

/* Return the value of the environment variable NAME.  This implementation
   is tuned a bit in that it assumes no environment variable has an empty
   name which of course should always be true.  We have a special case for
   one character names so that for the general case we can assume at least
   two characters which we can access.  By doing this we can avoid using the
   `strncmp' most of the time.  */

but I don't have the energy to dig through the complicated logic and
figure out what's going on.

The errors were of the form "invalid read of size 2 at the start of a 
block of size 1".  From the glibc getenv() code I don't think that is
the name to be looked up, but instead an entry in __environ.  So a 
1-char entry only has space for "=", so perhaps something in KDE added
some bogus entries to the environment and it is then hitting the assumption
in the glibc code that no variable has an empty name.

So perhaps it is a bug in KDE.  Who knows.

J