From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9788 Path: news.gmane.org!not-for-mail From: Max Ruttenberg Newsgroups: gmane.linux.lib.musl.general Subject: Re: Libc-Test: Tests failing on Ubuntu VM Date: Wed, 30 Mar 2016 14:14:41 -0400 Message-ID: References: <20160330164737.GL9862@port70.net> <20160330180442.GM9862@port70.net> <20160330181258.GT21636@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c04f8089ffeba052f481e6a X-Trace: ger.gmane.org 1459361716 12664 80.91.229.3 (30 Mar 2016 18:15:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Mar 2016 18:15:16 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9801-gllmg-musl=m.gmane.org@lists.openwall.com Wed Mar 30 20:15: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 1alKeA-0002RV-A5 for gllmg-musl@m.gmane.org; Wed, 30 Mar 2016 20:15:14 +0200 Original-Received: (qmail 20133 invoked by uid 550); 30 Mar 2016 18:15: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 20085 invoked from network); 30 Mar 2016 18:15:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emutechnology-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=/WYJgj5VxL76MMPXJZvWb9r8OobK+xq7Fc7AHS7X1lg=; b=KGsGlNSQwDCVw45E1XtIYzjJaCSP6IHYd58zMpyOkD+905oyDRAkpMTkYTjxaqa2wD yLIx4wW6+VZ8ZD6KcY8i2+bPg1GxSMrjWRLjNJEbuX+viZVLZpL8mdN2g79lMUQHHHsn 5PsPernNmT/k0ehW27kCzymY6hkhdJ5IzQSVJE1KErt4gC5ONCkWUeJCDxnQGdZ0jh8Y ghpoM9+sFtgz6fLG0Gc07WCoMnmBn2fZHWpAITADi2duwIu2+A/G4BuQJbgNwAud5iR5 hx7BHSEmutIpQgbfmWSdOvfe+IbH3YEreH4ssNji2GWFyjNNnrG+/uIo+RAGMmgO4R75 ZN1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=/WYJgj5VxL76MMPXJZvWb9r8OobK+xq7Fc7AHS7X1lg=; b=MzQ2uwAVatUGzNEUxESEul0fwNQ268ZnJd1gCExcKVEhMKOxZ4fHm7mG+NbwYue9hT KntsQTqQWUHd9dl8h7mm6FDXxHFqFcSuJusbIOgP+OrLalsYoHtr40SsOGGgqEayv0/1 Gp8CowPBDktTxVX8/nW3KnQitGKsY6t1vmzdl+LS3EY0p2T22fcS6BF7Wy6eeZ8tKg0y D14OTm+YYgBITaGOnA3rvP+PnTP1rIntMnCMoEgy1Hmluqyf983Ni+Grx+5AxlNQboNb PRXpat3RZzZOCFfTora3c/Z5Zp9/A90pu/2sk0FP2AZjd74ngdjLI4JxhihTiZ/BFxSf 7aGA== X-Gm-Message-State: AD7BkJJ7xilGRmVcgOkl0mwO5Ra8UKyRZqnoI5yQzDDDVMX9C2yWlC9PiHwHhLfad5blAa9qoUQGoB1IDVldtg== X-Received: by 10.157.2.33 with SMTP id 30mr6260191otb.175.1459361681484; Wed, 30 Mar 2016 11:14:41 -0700 (PDT) In-Reply-To: <20160330181258.GT21636@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:9788 Archived-At: --94eb2c04f8089ffeba052f481e6a Content-Type: text/plain; charset=UTF-8 > > 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 wrote: > 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 > - Max --94eb2c04f8089ffeba052f481e6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 figur= e 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 run= ning 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, 20= 16 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 ENO= MEM, 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 ENO= MEM, got
> > Operation not permitted
> > FAIL ./src/regression/malloc-brk-fail.exe [status 1]
> > src/regression/malloc-oom.c:16: expected ENOMEM, got Operation no= t permitted
> > FAIL ./src/regression/malloc-oom-static.exe [status 1]
> > src/regression/malloc-oom.c:16: expected ENOMEM, got Operation no= t permitted
> > FAIL ./src/regression/malloc-oom.exe [status 1]
> > FAIL ./src/regression/putenv-doublefree-static.exe [signal Segmen= tation
> > fault]
> > FAIL ./src/regression/putenv-doublefree.exe [signal Segmentation = fault]
> > src/regression/setenv-oom.c:23: expected ENOMEM, got Operation no= t permitted
> > FAIL ./src/regression/setenv-oom-static.exe [status 1]
> > src/regression/setenv-oom.c:23: expected ENOMEM, got Operation no= t permitted
> > FAIL ./src/regression/setenv-oom.exe [status 1]
> > *****************************************************************= *************************************************************
> >
> > Is the brk system call still kosher? I thought malloc was suppose= d 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
--94eb2c04f8089ffeba052f481e6a--