libc-test reports

libc-test reports

[Waldemar Brodkorb]

Hi,

I know Rich doesn't like the embedded-test Skript, because
the toolchains are build the first time it runs.
But here are the results from a complete run for 1.10
and git from yesterday:

http://tests.embedded-test.org/musl/

best regards
 Waldemar

Re: libc-test reports

[Szabolcs Nagy]

* Waldemar Brodkorb <wbx@openadk.org> [2015-06-18 07:47:33 +0200]:
> I know Rich doesn't like the embedded-test Skript, because
> the toolchains are build the first time it runs.
> But here are the results from a complete run for 1.10
> and git from yesterday:
> 
> http://tests.embedded-test.org/musl/
> 

thanks

i assume the x86 math errors are qemu's fault

but that does not explain all the failures..
i will look at it later

Re: libc-test reports

[Rich Felker]

On Thu, Jun 18, 2015 at 07:47:33AM +0200, Waldemar Brodkorb wrote:
> Hi,
> 
> I know Rich doesn't like the embedded-test Skript, because
> the toolchains are build the first time it runs.
> But here are the results from a complete run for 1.10
> and git from yesterday:

I don't dislike it; it's just not practical for re-running tests after
every compile during development, which is what I was looking to be
able to do.

Rich

Re: libc-test reports

[Rich Felker]

On Thu, Jun 18, 2015 at 11:33:02AM +0200, Szabolcs Nagy wrote:
> * Waldemar Brodkorb <wbx@openadk.org> [2015-06-18 07:47:33 +0200]:
> > I know Rich doesn't like the embedded-test Skript, because
> > the toolchains are build the first time it runs.
> > But here are the results from a complete run for 1.10
> > and git from yesterday:
> > 
> > http://tests.embedded-test.org/musl/
> > 
> 
> thanks
> 
> i assume the x86 math errors are qemu's fault
> 
> but that does not explain all the failures..
> i will look at it later

Looking at x86 (i386) results for 1.1.10:

iconv errors are wrong test assumptions; they fail with current musl.

sem_open segfault is probably failure of the test to handle
non-existence of /dev/shm or failure of it to have mode 1777; if so
this is an error in the test environment but it would be nice for the
test to report the error rather than crashing.

strtod failures on x86 are expected because of broken emulation.

remaining math issues I'll leave for nsz. :-)

fgets-eof-static looks like some linking breakage. It could indicate a
new toolchain bug we're not aware of, so I'd really like to see the
binary that crashes.

pthread-robust-detach is a broken test -- it's unstable under
timing/scheduling differences. It should use lock rather than trylock,
but then it would hang on failure. Timedlock with a 10-50ms timeout or
so would be a decent compromise.

regex-escaped-high-byte failure is odd. It should fail in musl git
without latest libc-test (because of byte-based C locale) but should
not fail on 1.1.10.

statvfs is probably a filesystem oddity of the test environment.

strverscmp is a known issue in musl, patch still pending review/merge.

Rich

Re: libc-test reports

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2015-06-18 14:51:08 -0400]:
> Looking at x86 (i386) results for 1.1.10:
> 
> iconv errors are wrong test assumptions; they fail with current musl.

fixed

> sem_open segfault is probably failure of the test to handle
> non-existence of /dev/shm or failure of it to have mode 1777; if so
> this is an error in the test environment but it would be nice for the
> test to report the error rather than crashing.

only sem_open-static.exe fails, so i'm not sure what's the problem

(if /dev/shm were broken then the failure of sem_open would be printed)

> strtod failures on x86 are expected because of broken emulation.
> 
> remaining math issues I'll leave for nsz. :-)

if the test machine is x86 with /dev/kvm then run qemu with --enable-kvm
(x87 emulation is too broken otherwise)

> fgets-eof-static looks like some linking breakage. It could indicate a
> new toolchain bug we're not aware of, so I'd really like to see the
> binary that crashes.

another weird -static only failure

> pthread-robust-detach is a broken test -- it's unstable under

fixed

> regex-escaped-high-byte failure is odd. It should fail in musl git
> without latest libc-test (because of byte-based C locale) but should
> not fail on 1.1.10.

current libc-test has setlocale(LC_CTYPE, "C.UTF-8");

Re: libc-test reports

[Szabolcs Nagy]

* Waldemar Brodkorb <wbx@openadk.org> [2015-06-18 07:47:33 +0200]:
> But here are the results from a complete run for 1.10
> and git from yesterday:
> 
> http://tests.embedded-test.org/musl/
> 

can you make these binaries available somewhere:
FAIL ./src/functional/sem_open-static.exe [signal Segmentation fault]
FAIL ./src/regression/fgets-eof-static.exe [signal Segmentation fault]

(for me the x86_64 versions are enough, you can mail them)

thanks

Re: libc-test reports

[Szabolcs Nagy]

* Szabolcs Nagy <nsz@port70.net> [2015-06-19 20:00:30 +0200]:
> * Waldemar Brodkorb <wbx@openadk.org> [2015-06-18 07:47:33 +0200]:
> > But here are the results from a complete run for 1.10
> > and git from yesterday:
> > 
> > http://tests.embedded-test.org/musl/
> > 
> 
> can you make these binaries available somewhere:
> FAIL ./src/functional/sem_open-static.exe [signal Segmentation fault]
> FAIL ./src/regression/fgets-eof-static.exe [signal Segmentation fault]
> 

ok, both of them die the exact same way:

brk(0)                                  = 0x1cf6000
brk(0x1cf8000)                          = 0x1cf8000
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x1cf5ff8} ---

a dereference 8 bytes before the first brk

there is no debug info, but based on the asm it seems to be
the p[-1] access in calloc.c:

	p = malloc(n);
	if (!p) return 0;
	/* Only do this for non-mmapped chunks */
	if (((size_t *)p)[-1] & 7) {

i think __simple_malloc is used in these tests.