Weekly reports: A

Weekly reports: A

[Luka Marčetić]

Hello.
I was going to keep you (at least) weekly informed of my plans and 
progress regarding "cluts" (C library unit test suite), and now that 
that's become the prescribed form of reporting, it's about time I start.
College requires me to spend time studying and doing projects this week. 
Regardless, I'll start doing real work now - as was the deal. In 
average, I expect to complete one task Rich described at 
http://openwall.info/wiki/musl/unit-tests?s=libc per each report. I'll 
start with nr. 1 (though there is nr. 0), as it allows me to correct and 
complete the proof-of-skill test I've written earlier.
Will report back when there's something to tell, until then, there's 
always XMPP.
-Luka M.

Re: Weekly reports: A

[Solar Designer]

Luka, Rich -

On Mon, May 23, 2011 at 07:42:38PM +0200, Luka Mar??eti?? wrote:
> average, I expect to complete one task Rich described at 
> http://openwall.info/wiki/musl/unit-tests?s=libc per each report. I'll 
> start with nr. 1 (though there is nr. 0), as it allows me to correct and 
> complete the proof-of-skill test I've written earlier.

(There are 13 test categories currently listed on the wiki page.)

Sounds fine to me.  I assume that you'll also proceed to wrap those
tests into a framework once you have a few initial tests implemented.

For "String operations testing" with "giant buffers (more than 2gb/4gb,
only possible on 64-bit machines)" (part of task nr. 1 that you intend
to work on now), you may consider having this test run on systems that
don't have this much virtual memory (but are 64-bit capable).  You may
achieve this by mmap()'ing the same pages many times.  When I needed a
large continuous pseudo-allocation like that to explore/exploit some
Linux kernel issues, I was able to allocate something like 190 GB (if I
recall correctly) on an Alpha with 128 MB RAM (that was in 1999, before
we got x86-64).  (The kernel would spend 25 minutes parsing that data.)

Of course, this enhancement should be optional (if implemented at all),
and you need to have a version of code that actually allocates large
buffers in straightforward manner (such that it's usable on systems that
might have any issues with the repeated mmap() approach).  In case you
don't have a machine with over 4 GB RAM (even though these are common
now) and need remote access to one, let me know.

Oh, it's also useful to test buffer sizes close to 2 GB and slightly
over 2 GB on 32-bit systems that are capable of such allocations.

For "low and high byte content", I suggest that you include ability to
test all byte values (for non-wide chars).  glibc and many other libc's
include implementations of string functions that use adds/bitmasks;
these might contain bugs that only show up with specific byte values in
specific character positions when the libc is built for specific CPUs.

These are just some suggestions, which Rich might override. ;-)

Thanks,

Alexander

Re: Weekly reports: A

[Rich Felker]

On Tue, May 24, 2011 at 05:00:29AM +0400, Solar Designer wrote:
> Luka, Rich -
> 
> On Mon, May 23, 2011 at 07:42:38PM +0200, Luka Mar??eti?? wrote:
> > average, I expect to complete one task Rich described at 
> > http://openwall.info/wiki/musl/unit-tests?s=libc per each report. I'll 
> > start with nr. 1 (though there is nr. 0), as it allows me to correct and 
> > complete the proof-of-skill test I've written earlier.
> 
> (There are 13 test categories currently listed on the wiki page.)
> 
> Sounds fine to me.  I assume that you'll also proceed to wrap those
> tests into a framework once you have a few initial tests implemented.

Yes, I'd like him to get some more tests working first though. A good
design for the framework should become more apparent when you have
tests to try integrating.

> For "String operations testing" with "giant buffers (more than 2gb/4gb,
> only possible on 64-bit machines)" (part of task nr. 1 that you intend
> to work on now), you may consider having this test run on systems that
> don't have this much virtual memory (but are 64-bit capable).  You may
> achieve this by mmap()'ing the same pages many times.  When I needed a
> large continuous pseudo-allocation like that to explore/exploit some
> Linux kernel issues, I was able to allocate something like 190 GB (if I
> recall correctly) on an Alpha with 128 MB RAM (that was in 1999, before
> we got x86-64).  (The kernel would spend 25 minutes parsing that data.)

Another option is using a giant file. Even if you don't want to take
that approach, you could start with a giant sparse file to mmap in
order to allocate the virtual address space, then mmap over top of it
with the MAP_FIXED option to achieve the above.

> Oh, it's also useful to test buffer sizes close to 2 GB and slightly
> over 2 GB on 32-bit systems that are capable of such allocations.

musl's malloc refuses to allocate >2gb on 32-bit systems to avoid the
ptrdiff_t overflow issue, but mmap could still potentially create such
large objects.

> For "low and high byte content", I suggest that you include ability to
> test all byte values (for non-wide chars).  glibc and many other libc's
> include implementations of string functions that use adds/bitmasks;
> these might contain bugs that only show up with specific byte values in
> specific character positions when the libc is built for specific CPUs.

I agree. I don't believe any such issues affect the current C
implementations in musl, but it would be nice to have the tests in
place in case anyone wants to add arch-specific asm versions.

> These are just some suggestions, which Rich might override. ;-)

They sound very good to me.

Rich

Re: Weekly reports: A

[Luka Marčetić]

On 05/24/2011 03:13 AM, Rich Felker wrote:
>> >  For "low and high byte content", I suggest that you include ability to
>> >  test all byte values (for non-wide chars).  glibc and many other libc's
>> >  include implementations of string functions that use adds/bitmasks;
>> >  these might contain bugs that only show up with specific byte values in
>> >  specific character positions when the libc is built for specific CPUs.
>>      
> I agree. I don't believe any such issues affect the current C
> implementations in musl, but it would be nice to have the tests in
> place in case anyone wants to add arch-specific asm versions.
>    

Hey guys.
I would just like to point out that the above, combined with the "all 
alignments" requirement from the wiki means I'm essentially 
brute-forcing string.h functions. While I generally dislike the idea, 
it's a.. thorough approach.. I guess. As a slight remedy I'll "brute 
force" with smaller buffers, and only do basic tests with huge ones. I 
hope that won't miss the point then. Will report how mmaping more than a 
single GiB goes (1 is what I have).
Good night,
-Luka

Re: Weekly reports: A

[Rich Felker]

On Sat, May 28, 2011 at 02:37:46AM +0200, Luka Marčetić wrote:
> On 05/24/2011 03:13 AM, Rich Felker wrote:
> >>>  For "low and high byte content", I suggest that you include ability to
> >>>  test all byte values (for non-wide chars).  glibc and many other libc's
> >>>  include implementations of string functions that use adds/bitmasks;
> >>>  these might contain bugs that only show up with specific byte values in
> >>>  specific character positions when the libc is built for specific CPUs.
> >I agree. I don't believe any such issues affect the current C
> >implementations in musl, but it would be nice to have the tests in
> >place in case anyone wants to add arch-specific asm versions.
> 
> Hey guys.
> I would just like to point out that the above, combined with the
> "all alignments" requirement from the wiki means I'm essentially
> brute-forcing string.h functions. While I generally dislike the
> idea, it's a.. thorough approach.. I guess. As a slight remedy I'll

The whole point is to brute force all combinations of input that are
expected to make a difference to what paths the code might take.

> "brute force" with smaller buffers, and only do basic tests with
> huge ones. I hope that won't miss the point then. Will report how

Indeed of course you can't brute force all possible sequences of bytes
up to several GB. :-) I'll leave coming up with a reasonable
evalulation of what's needed and what's not as part of your task.

Rich