Libc-Test: Tests failing on Ubuntu VM

Libc-Test: Tests failing on Ubuntu VM

[Max Ruttenberg]

[-- Attachment #1: Type: text/plain, Size: 4501 bytes --]

All,

Feel free to let me know if this is the wrong mailing list for this
question.

I've built musl on an Ubuntu VM (x86_64 is the architecture) and have
installed it to an install directory inside the downloaded clone.

So the compiler is in: /path/to/musl/install/bin/musl-gcc

The loader is in: /path/to/musl/install/lib/libc.so

At the top level of libc-test I run a make like so:

make CC=/path/to/musl/bin/musl-gcc RUN_WRAP=/path/to/musl/lib/libc.so

The tests run, I don't get the "no such file or directory" error. But for
some reason a bunch of tests fail that shouldn't according to the Libc-Test
wiki. What am I doing wrong? Are these tests dependent on system resources
that maybe I'm not providing e.g. enough memory? Do I need to run as a sudo
user as might be suggested by the "Operation not permitted" errors?

This is what I find in libc-test/src/functional/REPORT:

***************************************************************
FAIL ./src/functional/argv-static.exe [status 1]
FAIL ./src/functional/basename-static.exe [status 1]
FAIL ./src/functional/clock_gettime-static.exe [status 1]
FAIL ./src/functional/crypt-static.exe [status 1]
FAIL ./src/functional/dirname-static.exe [status 1]
FAIL ./src/functional/env-static.exe [status 1]
FAIL ./src/functional/fcntl-static.exe [status 1]
FAIL ./src/functional/fdopen-static.exe [status 1]
FAIL ./src/functional/fnmatch-static.exe [status 1]
FAIL ./src/functional/fscanf-static.exe [status 1]
FAIL ./src/functional/fwscanf-static.exe [status 1]
FAIL ./src/functional/iconv_open-static.exe [status 1]
FAIL ./src/functional/inet_pton-static.exe [status 1]
FAIL ./src/functional/ipc_msg-static.exe [status 1]
FAIL ./src/functional/ipc_sem-static.exe [status 1]
FAIL ./src/functional/ipc_shm-static.exe [status 1]
FAIL ./src/functional/mbc-static.exe [status 1]
FAIL ./src/functional/memstream-static.exe [status 1]
FAIL ./src/functional/popen-static.exe [status 1]
FAIL ./src/functional/pthread_cancel-points-static.exe [status 1]
FAIL ./src/functional/pthread_cancel-static.exe [status 1]
FAIL ./src/functional/pthread_cond-static.exe [status 1]
FAIL ./src/functional/pthread_mutex-static.exe [status 1]
FAIL ./src/functional/pthread_robust-static.exe [status 1]
FAIL ./src/functional/pthread_tsd-static.exe [status 1]
FAIL ./src/functional/qsort-static.exe [status 1]
FAIL ./src/functional/random-static.exe [status 1]
FAIL ./src/functional/search_hsearch-static.exe [status 1]
FAIL ./src/functional/search_insque-static.exe [status 1]
FAIL ./src/functional/search_lsearch-static.exe [status 1]
FAIL ./src/functional/search_tsearch-static.exe [status 1]
FAIL ./src/functional/sem_init-static.exe [status 1]
FAIL ./src/functional/sem_open-static.exe [status 1]
FAIL ./src/functional/setjmp-static.exe [status 1]
FAIL ./src/functional/snprintf-static.exe [status 1]
FAIL ./src/functional/socket-static.exe [status 1]
FAIL ./src/functional/spawn-static.exe [status 1]
FAIL ./src/functional/sscanf-static.exe [status 1]
FAIL ./src/functional/sscanf_long-static.exe [status 1]
FAIL ./src/functional/stat-static.exe [status 1]
FAIL ./src/functional/string-static.exe [status 1]
FAIL ./src/functional/string_memcpy-static.exe [status 1]
FAIL ./src/functional/string_memmem-static.exe [status 1]
FAIL ./src/functional/string_memset-static.exe [status 1]
FAIL ./src/functional/string_strchr-static.exe [status 1]
FAIL ./src/functional/string_strcspn-static.exe [status 1]
FAIL ./src/functional/string_strstr-static.exe [status 1]
FAIL ./src/functional/strtod-static.exe [status 1]
FAIL ./src/functional/strtod_long-static.exe [status 1]
FAIL ./src/functional/strtod_simple-static.exe [status 1]
FAIL ./src/functional/strtof-static.exe [status 1]
FAIL ./src/functional/strtol-static.exe [status 1]
FAIL ./src/functional/strtold-static.exe [status 1]
FAIL ./src/functional/swprintf-static.exe [status 1]
FAIL ./src/functional/tgmath-static.exe [status 1]
FAIL ./src/functional/time-static.exe [status 1]
FAIL ./src/functional/tls_align-static.exe [status 1]
FAIL ./src/functional/tls_init-static.exe [status 1]
FAIL ./src/functional/udiv-static.exe [status 1]
FAIL ./src/functional/ungetc-static.exe [status 1]
FAIL ./src/functional/vfork-static.exe [status 1]
FAIL ./src/functional/wcsstr-static.exe [status 1]
FAIL ./src/functional/wcstol-static.exe [status 1]
src/functional/wcstol.c:50: 0 failed (64bit tests not implemented)
FAIL ./src/functional/wcstol.exe [status 1]
***************************************************************

Max

[-- Attachment #2: Type: text/html, Size: 5509 bytes --]

Re: Libc-Test: Tests failing on Ubuntu VM

[Szabolcs Nagy]

* Max Ruttenberg <mruttenberg@emutechnology.com> [2016-03-30 12:18:33 -0400]:
> I've built musl on an Ubuntu VM (x86_64 is the architecture) and have
> installed it to an install directory inside the downloaded clone.
> 
> So the compiler is in: /path/to/musl/install/bin/musl-gcc
> 
> The loader is in: /path/to/musl/install/lib/libc.so
> 
> At the top level of libc-test I run a make like so:
> 
> make CC=/path/to/musl/bin/musl-gcc RUN_WRAP=/path/to/musl/lib/libc.so
> 

that's not the intended usage

RUN_WRAP is for qemu or similar tools for running the binaries

you can specify the libc.so by changing the dynamic-linker name
(at least that's enough in case of musl) or installing the
musl-gcc wrapper/musl based toolchain with different dynamic-linker
name, e.g.

make CC='/path/to/musl/bin/musl-gcc -Wl,-dynamic-linker=/path/to/musl/lib/libc.so'

should work (not tested)

> The tests run, I don't get the "no such file or directory" error. But for
> some reason a bunch of tests fail that shouldn't according to the Libc-Test
> wiki. What am I doing wrong? Are these tests dependent on system resources
> that maybe I'm not providing e.g. enough memory? Do I need to run as a sudo
> user as might be suggested by the "Operation not permitted" errors?
> 

static linked binaries cannot be loaded by libc.so so all *-static.exe
failed to run.

Re: Libc-Test: Tests failing on Ubuntu VM

[Max Ruttenberg]

[-- Attachment #1: Type: text/plain, Size: 3206 bytes --]

Szabolcs,

Thank you! That was helpful. I have a couple of tests that still fail in
functional but they clearly state "64bit tests not implemented."
I still have a bunch of tests that fail in regression though...

Running a make like so:

make CC='/path/to/musl/bin/musl-gcc -Wl,-dynamic-linker=/path/to/
> musl/lib/libc.so'
>

this is what my src/regression/REPORT file looks like:

******************************************************************************************************************************
src/regression/malloc-brk-fail.c:33: malloc did not fail with ENOMEM, got
Operation not permitted
FAIL ./src/regression/malloc-brk-fail-static.exe [status 1]
src/regression/malloc-brk-fail.c:33: malloc did not fail with ENOMEM, got
Operation not permitted
FAIL ./src/regression/malloc-brk-fail.exe [status 1]
src/regression/malloc-oom.c:16: expected ENOMEM, got Operation not permitted
FAIL ./src/regression/malloc-oom-static.exe [status 1]
src/regression/malloc-oom.c:16: expected ENOMEM, got Operation not permitted
FAIL ./src/regression/malloc-oom.exe [status 1]
FAIL ./src/regression/putenv-doublefree-static.exe [signal Segmentation
fault]
FAIL ./src/regression/putenv-doublefree.exe [signal Segmentation fault]
src/regression/setenv-oom.c:23: expected ENOMEM, got Operation not permitted
FAIL ./src/regression/setenv-oom-static.exe [status 1]
src/regression/setenv-oom.c:23: expected ENOMEM, got Operation not permitted
FAIL ./src/regression/setenv-oom.exe [status 1]
******************************************************************************************************************************

Is the brk system call still kosher? I thought malloc was supposed to use
something mmap.


On Wed, Mar 30, 2016 at 12:47 PM, Szabolcs Nagy <nsz@port70.net> wrote:

> * Max Ruttenberg <mruttenberg@emutechnology.com> [2016-03-30 12:18:33
> -0400]:
> > I've built musl on an Ubuntu VM (x86_64 is the architecture) and have
> > installed it to an install directory inside the downloaded clone.
> >
> > So the compiler is in: /path/to/musl/install/bin/musl-gcc
> >
> > The loader is in: /path/to/musl/install/lib/libc.so
> >
> > At the top level of libc-test I run a make like so:
> >
> > make CC=/path/to/musl/bin/musl-gcc RUN_WRAP=/path/to/musl/lib/libc.so
> >
>
> that's not the intended usage
>
> RUN_WRAP is for qemu or similar tools for running the binaries
>
> you can specify the libc.so by changing the dynamic-linker name
> (at least that's enough in case of musl) or installing the
> musl-gcc wrapper/musl based toolchain with different dynamic-linker
> name, e.g.
>
> make CC='/path/to/musl/bin/musl-gcc
> -Wl,-dynamic-linker=/path/to/musl/lib/libc.so'
>
> should work (not tested)
>
> > The tests run, I don't get the "no such file or directory" error. But for
> > some reason a bunch of tests fail that shouldn't according to the
> Libc-Test
> > wiki. What am I doing wrong? Are these tests dependent on system
> resources
> > that maybe I'm not providing e.g. enough memory? Do I need to run as a
> sudo
> > user as might be suggested by the "Operation not permitted" errors?
> >
>
> static linked binaries cannot be loaded by libc.so so all *-static.exe
> failed to run.
>



-Max

[-- Attachment #2: Type: text/html, Size: 4564 bytes --]

Re: Libc-Test: Tests failing on Ubuntu VM

[Szabolcs Nagy]

* Max Ruttenberg <mruttenberg@emutechnology.com> [2016-03-30 13:22:19 -0400]:
> this is what my src/regression/REPORT file looks like:
> 
> ******************************************************************************************************************************
> src/regression/malloc-brk-fail.c:33: malloc did not fail with ENOMEM, got
> Operation not permitted
> FAIL ./src/regression/malloc-brk-fail-static.exe [status 1]
> src/regression/malloc-brk-fail.c:33: malloc did not fail with ENOMEM, got
> Operation not permitted
> FAIL ./src/regression/malloc-brk-fail.exe [status 1]
> src/regression/malloc-oom.c:16: expected ENOMEM, got Operation not permitted
> FAIL ./src/regression/malloc-oom-static.exe [status 1]
> src/regression/malloc-oom.c:16: expected ENOMEM, got Operation not permitted
> FAIL ./src/regression/malloc-oom.exe [status 1]
> FAIL ./src/regression/putenv-doublefree-static.exe [signal Segmentation
> fault]
> FAIL ./src/regression/putenv-doublefree.exe [signal Segmentation fault]
> src/regression/setenv-oom.c:23: expected ENOMEM, got Operation not permitted
> FAIL ./src/regression/setenv-oom-static.exe [status 1]
> src/regression/setenv-oom.c:23: expected ENOMEM, got Operation not permitted
> FAIL ./src/regression/setenv-oom.exe [status 1]
> ******************************************************************************************************************************
> 
> Is the brk system call still kosher? I thought malloc was supposed to use
> something mmap.
> 

i've seen such things: mmap fails with EPERM
instead of ENOMEM when the system runs out of
virtual address space, i don't remember the
details though, you can debug it with strace.

if you figure it out i'd like to know when
this happens (probably a kernel bug).

putenv-doublefree was recently fixed, so
your musl is probably not up to date.

Re: Libc-Test: Tests failing on Ubuntu VM

[Rich Felker]

On Wed, Mar 30, 2016 at 08:04:43PM +0200, Szabolcs Nagy wrote:
> * Max Ruttenberg <mruttenberg@emutechnology.com> [2016-03-30 13:22:19 -0400]:
> > this is what my src/regression/REPORT file looks like:
> > 
> > ******************************************************************************************************************************
> > src/regression/malloc-brk-fail.c:33: malloc did not fail with ENOMEM, got
> > Operation not permitted
> > FAIL ./src/regression/malloc-brk-fail-static.exe [status 1]
> > src/regression/malloc-brk-fail.c:33: malloc did not fail with ENOMEM, got
> > Operation not permitted
> > FAIL ./src/regression/malloc-brk-fail.exe [status 1]
> > src/regression/malloc-oom.c:16: expected ENOMEM, got Operation not permitted
> > FAIL ./src/regression/malloc-oom-static.exe [status 1]
> > src/regression/malloc-oom.c:16: expected ENOMEM, got Operation not permitted
> > FAIL ./src/regression/malloc-oom.exe [status 1]
> > FAIL ./src/regression/putenv-doublefree-static.exe [signal Segmentation
> > fault]
> > FAIL ./src/regression/putenv-doublefree.exe [signal Segmentation fault]
> > src/regression/setenv-oom.c:23: expected ENOMEM, got Operation not permitted
> > FAIL ./src/regression/setenv-oom-static.exe [status 1]
> > src/regression/setenv-oom.c:23: expected ENOMEM, got Operation not permitted
> > FAIL ./src/regression/setenv-oom.exe [status 1]
> > ******************************************************************************************************************************
> > 
> > Is the brk system call still kosher? I thought malloc was supposed to use
> > something mmap.
> > 
> 
> i've seen such things: mmap fails with EPERM
> instead of ENOMEM when the system runs out of
> virtual address space, i don't remember the
> details though, you can debug it with strace.
> 
> if you figure it out i'd like to know when
> this happens (probably a kernel bug).

We should probably work around this kernel bug by not trusting mmap to
set errno and instead just setting it to ENOMEM on failure (in the
malloc code at least; working around it in the mmap function may be
more work becaus EPERM is a valid error for some usage cases).

Rich

Re: Libc-Test: Tests failing on Ubuntu VM

[Max Ruttenberg]

[-- Attachment #1: Type: text/plain, Size: 2865 bytes --]

>
> i've seen such things: mmap fails with EPERM
> instead of ENOMEM when the system runs out of
> virtual address space, i don't remember the
> details though, you can debug it with strace.


Interesting.

if you figure it out i'd like to know when
> this happens (probably a kernel bug).


I'll see what I can find. If it's of interest/help I'm running on the
3.19.0-56-generic Linux Kernel.

putenv-doublefree was recently fixed, so
> your musl is probably not up to date.


That's very likely.

Thank you!

On Wed, Mar 30, 2016 at 2:12 PM, Rich Felker <dalias@libc.org> wrote:

> On Wed, Mar 30, 2016 at 08:04:43PM +0200, Szabolcs Nagy wrote:
> > * Max Ruttenberg <mruttenberg@emutechnology.com> [2016-03-30 13:22:19
> -0400]:
> > > this is what my src/regression/REPORT file looks like:
> > >
> > >
> ******************************************************************************************************************************
> > > src/regression/malloc-brk-fail.c:33: malloc did not fail with ENOMEM,
> got
> > > Operation not permitted
> > > FAIL ./src/regression/malloc-brk-fail-static.exe [status 1]
> > > src/regression/malloc-brk-fail.c:33: malloc did not fail with ENOMEM,
> got
> > > Operation not permitted
> > > FAIL ./src/regression/malloc-brk-fail.exe [status 1]
> > > src/regression/malloc-oom.c:16: expected ENOMEM, got Operation not
> permitted
> > > FAIL ./src/regression/malloc-oom-static.exe [status 1]
> > > src/regression/malloc-oom.c:16: expected ENOMEM, got Operation not
> permitted
> > > FAIL ./src/regression/malloc-oom.exe [status 1]
> > > FAIL ./src/regression/putenv-doublefree-static.exe [signal Segmentation
> > > fault]
> > > FAIL ./src/regression/putenv-doublefree.exe [signal Segmentation fault]
> > > src/regression/setenv-oom.c:23: expected ENOMEM, got Operation not
> permitted
> > > FAIL ./src/regression/setenv-oom-static.exe [status 1]
> > > src/regression/setenv-oom.c:23: expected ENOMEM, got Operation not
> permitted
> > > FAIL ./src/regression/setenv-oom.exe [status 1]
> > >
> ******************************************************************************************************************************
> > >
> > > Is the brk system call still kosher? I thought malloc was supposed to
> use
> > > something mmap.
> > >
> >
> > i've seen such things: mmap fails with EPERM
> > instead of ENOMEM when the system runs out of
> > virtual address space, i don't remember the
> > details though, you can debug it with strace.
> >
> > if you figure it out i'd like to know when
> > this happens (probably a kernel bug).
>
> We should probably work around this kernel bug by not trusting mmap to
> set errno and instead just setting it to ENOMEM on failure (in the
> malloc code at least; working around it in the mmap function may be
> more work becaus EPERM is a valid error for some usage cases).
>
> Rich
>



- Max

[-- Attachment #2: Type: text/html, Size: 4721 bytes --]