Re: current state of sid (unstable)

Re: current state of sid (unstable)

[Michael Cree]

On 04/08/10 09:35, Michael Cree wrote:
> On 4/08/2010, at 1:48 AM, Bob Tracy wrote:
>> (5) Some long-standing compiler and libc issues have been fixed
>> upstream and in Debian, but recently, a build of libc in Debian
>> Unstable failed.
>
> I see the memchr seg fault bug (521737) is still open. I have a hunch
> that it may be a false-positive,

Darn, it's a true-positive.

>  It's a standard ldq_u for loading a byte within a
> quadword that is failing. If the correct quadword is being loaded then
> that shouldn't trip a seg fault no matter what byte in it is being
> loaded, even if the byte is pass the end of the string, right?

If there are fewer than eight bytes to search it loads a quadword (via 
ldq_u) encompassing the address one byte before the start address plus 
the length to search.  If the start address is quadword aligned then 
that will always be safe, but it appears to me that the author forgot 
about the possibility that the start address may not be quadword 
aligned, and then adding on the length-1 may step across the next 
quadword boundary, and whoops, we've gone past the valid end of buffer.

The problem is in both the Alpha generic and the Alpha ev6 code for 
memchr in libc.

Ohh, the kernel code (arch/alpha/lib/memchr.S) has the same problem!

Cheers
Michael.

Re: current state of sid (unstable)

[Michael Cree]

On 20/09/10 22:18, Michael Cree wrote:
> On 04/08/10 09:35, Michael Cree wrote:
>> On 4/08/2010, at 1:48 AM, Bob Tracy wrote:
>>> (5) Some long-standing compiler and libc issues have been fixed
>>> upstream and in Debian, but recently, a build of libc in Debian
>>> Unstable failed.
>>
>> I see the memchr seg fault bug (521737) is still open. I have a hunch
>> that it may be a false-positive,
>
> Darn, it's a true-positive.

A new version of memchr is now upstream in the glibc ports repository 
(many thanks to RTH). In addition to fixing the seg fault it is more 
than twice as fast as the old version when searching through large 
memory buffers.

Cheers
Michael.