[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130701205856.GS15323@port70.net>
Date: Mon, 1 Jul 2013 22:58:57 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Request for volunteers
* Rich Felker <dalias@...ifal.cx> [2013-06-30 23:51:17 -0400]:
> This could involve tasks like:
>
> - Reading the git log and making a list of noteworthy bugs to add
> regression tests for.
>
> - Determining (perhaps via automated coverage tools) major code we
> lack any testing for.
>
> - Cross-checking glibc bug tracker and/or glibc tests for issues that
> should be checked in musl too.
i was thinking about this and a few category of tests:
functional:
black box testing of libc interfaces
(eg input-output test vectors)
tries to achieve good coverage
regression:
tests for bugs we found
sometimes the bugs are musl specific or arch specific so
i think these are worth keeping separately from the general
functional tests (eg same repo but different dir)
static:
testing without executing code
eg check the symbols and types in headers
(i have tests that cover all posix headers only using cc)
may be the binaries can be checked in some way as well
static-src:
code analyzis can be done on the source of musl
(eg sparse, cppcheck, clang-analyzer were tried earlier)
(this is different from the other tests and probably should
be set up separately)
metrics:
benchmarks and quality of implementation metrics
(eg performance, memory usage the usual checks but even
ulp error measurements may be in this category)
other tools:
a coverage tool would be useful, i'm not sure if anyone
set up one with musl yet (it's not just good for testing,
but also for determining what interfaces are actually in
use in the libc)
clever fuzzer tools would be nice as well, but i don't know
anything that can be used directly on a library (maybe with
small effort they can be used to get better coverage)
as a first step i guess we need to start with the functional
and regression tests
design goals of the test system:
- tests should be easy to run even a single test in isolation
(so test should be self contained if possible)
- output is a report, failure cause should be clear
- the system should not have external dependencies
(other than libc, posix sh, gnu make: so tests are in .c files with
simple buildsystem or .sh wrapper)
- the failure of one test should not interfere with other tests
(so tests should be in separate .c files each with main() and
narrow scope, otherwise a build failure can affect a lot of tests)
- the test system should run on all archs
(so arch specific and implementation defined things should be treated
carefully)
- the test results should be robust
(failures are always reported, deterministically if possible)
- tests should leave the system in clean state
(or easily cleanable state)
some difficulties:
- some "test framework" functionality would be nice, but can be
problematic: eg using nice error reporting function on top of stdio
may cause loss of info because of buffering in case of a crash
- special compiler or linker flags (can be maintained in makefile
or in the .c files as comments)
- tests may require special environment, filesystem access, etc
i'm not sure what's the best way to manage that
(and some tests may need two different uid or other capabilities)
- i looked at the bug history and many bugs are in hard to
trigger cornercases (eg various races) or internally invoke ub
in a way that may be hard to verify in a robust way
- some tests may need significant support code to achieve good
coverage (printf, math, string handling close to 2G,..)
(in such cases we can go with simple self-contained tests without
much coverage, but easy maintainance, or with something
sophisticated)
does that sound right?
i think i can reorganize my libc tests to be more "scalabe"
in these directions..
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
