Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 18 Jun 2015 14:51:08 -0400
From: Rich Felker <>
Subject: Re: libc-test reports

On Thu, Jun 18, 2015 at 11:33:02AM +0200, Szabolcs Nagy wrote:
> * Waldemar Brodkorb <> [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:
> > 
> >
> > 
> 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.


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.