From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9787 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Libc-Test: Tests failing on Ubuntu VM Date: Wed, 30 Mar 2016 14:12:58 -0400 Message-ID: <20160330181258.GT21636@brightrain.aerifal.cx> References: <20160330164737.GL9862@port70.net> <20160330180442.GM9862@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1459361600 10396 80.91.229.3 (30 Mar 2016 18:13:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Mar 2016 18:13:20 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9800-gllmg-musl=m.gmane.org@lists.openwall.com Wed Mar 30 20:13:15 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1alKcE-0001oM-Ef for gllmg-musl@m.gmane.org; Wed, 30 Mar 2016 20:13:14 +0200 Original-Received: (qmail 18106 invoked by uid 550); 30 Mar 2016 18:13:12 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 18088 invoked from network); 30 Mar 2016 18:13:11 -0000 Content-Disposition: inline In-Reply-To: <20160330180442.GM9862@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9787 Archived-At: On Wed, Mar 30, 2016 at 08:04:43PM +0200, Szabolcs Nagy wrote: > * Max Ruttenberg [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