[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: broken memchr

From: Simon Josefsson
Subject: Re: broken memchr
Date: Tue, 26 May 2009 18:24:53 +0200
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)

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:



reply via email to

[Prev in Thread] Current Thread [Next in Thread]