mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Libc-Test: Tests failing on Ubuntu VM
Date: Wed, 30 Mar 2016 14:12:58 -0400	[thread overview]
Message-ID: <20160330181258.GT21636@brightrain.aerifal.cx> (raw)
In-Reply-To: <20160330180442.GM9862@port70.net>

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


  reply	other threads:[~2016-03-30 18:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-30 16:18 Max Ruttenberg
2016-03-30 16:47 ` Szabolcs Nagy
2016-03-30 17:22   ` Max Ruttenberg
2016-03-30 18:04     ` Szabolcs Nagy
2016-03-30 18:12       ` Rich Felker [this message]
2016-03-30 18:14         ` Max Ruttenberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160330181258.GT21636@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).