From: Carlos Martín Nieto <cmn@elego.de>
Date: Wed, 16 Mar 2011 11:10:14 GMT
Subject: Re: [PATCH] valgrind: ignore SSE-based strlen invalid reads
Message-ID: <1300273819.7214.12.camel@bee.lab.cmartin.tk>
In-Reply-To: <20110316105214.GB8277@elie>

On mié, 2011-03-16 at 05:52 -0500, Jonathan Nieder wrote:
> Carlos Martín Nieto wrote:
> 
> > The GNU C Library (glibc) uses SSE instructions to make strlen (among
> > others) faster, loading 4 bytes at a time and reading past the end of
> > the allocated memory. This read is safe and when the strlen function
> > is inlined, it is (obviously) not replaced by valgrind, which reports
> > a false-possitive.
> 
> This still makes no sense to me.  How is it possible to inline a
> function from glibc?  When I look in /usr/include/string.h, I see
> 
> extern size_t strlen (__const char *__s)
>      __THROW __attribute_pure__ __nonnull ((1));

 Looking at that header, strlen is one of the few functions not being
replaced by its __builtin version, and I only see __builtin_strlen in
the C++ patches. I'll rephrase to something like "Some versions of
strlen use SSE which then get inlined" to avoid blaming anyone in
particular, though thinking about it, it does seem logical that it's
GCC's builtin strlen.

> 
> > Tell valgrind to ignore this particular error, as the read is, in
> > fact, safe.
> 
> I'm happy to see a workaround.  I would be even happier if it came
> with documentation about which versions of valgrind need it.

 I think 3.6.1 doesn't need it, as Debian's 1:3.5.0+3.6.0svn20100609-1
version is reportedly fixed. I'll see if I can find more information in
the valgrind bug tracker.

 Cheers,
   cmn