Re: broken memchr

[Simon Josefsson]

Eric Blake <address@hidden> writes:

> Simon Josefsson <simon <at> josefsson.org> writes:
>
>> >> + * tests/test-strstr.c: Add another self-test.
>> >>    {
>> >> +    /* See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521737 */
>> >> +    char *input = strdup ("aBaaaaaaaaaaax");
>> >
>> > Did you take the proper precautions to ensure strdup is available?  I'd
>> > almost feel better if you rewrote this to use malloc/strcpy, rather than
>> > dragging in dependencies just for the test.
>> 
>> Good point.  Pushed.
>
> Thanks.  But thinking about it more, this doesn't tickle the memchr bug 
> unless 
> you are running under efence or other memory checker, so even on platforms 
> where the bug is still present, we are not likely to get failure reports.  
> Remember, the bug is that memchr dereferences too much memory when the result 
> is found early, but this is only fatal if the dereferenced memory was 
> unreadable in the first place.  What would be better would be using Bruno's 
> recent addition of tests/zerosize-ptr.h as a starting point to write code 
> that 
> allocates a 2-page fenced memory region ourselves, then placing the 
> problematic 
> string such that the trailing '\0' is the last dereferenceable byte before 
> the 
> protected page, so that we can expose the alpha-specific glibc bug in memchr 
> even without the use of efence.

Sounds good to me.

> And with the recent thread of memchr also being broken on x86_64, I'm 
> starting 
> to think that we need to do something like this.  I don't have access to 
> either 
> x86_64 or alpha, so I don't know if this is sufficient to detect the broken 
> memchr implementations out there; comments are welcome on whether we should 
> polish and apply this patch.

My gnulib autobuilder is a x86_64 system (running Ubuntu 8.04 LTS), so
if the test starts to fail, it will show up here in a few hours:

http://autobuild.josefsson.org/gnulib/#000-gnulib-simple-gaggia

/Simon