[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210427205555.GL2799122@port70.net>
Date: Tue, 27 Apr 2021 22:55:55 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: Érico Nogueira <ericonr@...root.org>,
Matus Kysel <mkysel@...hyum.com>
Cc: musl@...ts.openwall.com
Subject: Re: Re: libc-test issue with sem_close
* Érico Nogueira <ericonr@...root.org> [2021-04-27 17:49:45 -0300]:
> Em 27/04/2021 17:33, Érico Nogueira escreveu:
> > Em 27/04/2021 16:55, Szabolcs Nagy escreveu:
> > > * Matus Kysel <mkysel@...hyum.com> [2021-04-26 09:49:35 +0000]:
> > > > Hi Szabolcs,
> > > >
> > > > I am using your library as part of my validation suite and
> > > > recently I have updated it to latest master, but the sem_close
> > > > test is not buildable for me as it is missing fcntl.h header. I
> > > > have attached possible fix, because I did not found how to
> > > > contribute to you repo.
> > >
> > > ccing musl, libc-test is mostly discussed there.
> > >
> > > posix says
> > >
> > > "Inclusion of the <semaphore.h> header may make visible symbols
> > > defined in the <fcntl.h> and <time.h> headers."
> > >
> > > https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/semaphore.h.html
> > >
> > >
> > > which sounds optional, not guaranteed visibility of O_ open flags in
> > > semaphore.h, but sem_open is expected to be usable with only semaphore.h
> > >
> > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/sem_open.html
> > >
> > > i'm not sure what is the strict standard requirement here, without
> > > clarification i consider it a libc header issue if an api is not usable
> > > with just the header where it is declared.
> > >
> >
> > The linux man page for sem_open(3) says including <fcntl.h> is necessary
> > for the flags, and indeed the test fails to build on glibc.
> >
> > The oflag argument specifies flags that control the operation of the
> > call. (Definitions of the flags values can be obtained by including
> > <fcntl.h>.)
> >
> > sem_open(name, 0) works without <fcntl.h>, otherwise it's necessary.
> >
> > Taking advantage of the fact that the regressions/sem_close-unmap test
> > has been brought up, it has some interesting results:
> >
> > On glibc 2.32:
> > - works with dynamic linking
> > - segfaults in sem_open() with static linking (might be something wrong
> > with the build?)
> >
> > On musl 1.2.2:
> > - segfaults most of the time (always?)
>
> My mistake, I was on 1.2.1.
>
> >
> > On musl master (aad50fcd791e009961621ddfbe3d4c245fd689a3):
> > - completes successfully most of the time, segfaults ever so often
> > (which would lead me to assume the fix from
> > f70375df85d26235a45e74559afd69be59e5ff99 wasn't enough)
>
> The sem_create() calls can sometimes fail here with EINVAL because sem_open
> is being called with the wrong number of arguments. Included patch to fix
> it.
thanks for looking into this.
based on this i applied both patches (include fcntl.h and the argument fix).
> From bb113fe0b0e209681b1c0d6317440bf64f57ea80 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?=C3=89rico=20Nogueira?= <ericonr@...root.org>
> Date: Tue, 27 Apr 2021 17:46:17 -0300
> Subject: [PATCH] fix sem_close regression test
>
> sem_close with O_CREAT takes 4 parameters, not 3. The last parameter,
> the initial value for the semaphore, had an arbitrary value from
> whatever was on the stack, and lead to spurious failures with EINVAL
> when it happened to be greater than SEM_VALUE_MAX. Since there isn't
> error checking in this test, this lead to a segfault in the first
> sem_post call.
> ---
> src/regression/sem_close-unmap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/regression/sem_close-unmap.c b/src/regression/sem_close-unmap.c
> index f1e51d9..73c53e3 100644
> --- a/src/regression/sem_close-unmap.c
> +++ b/src/regression/sem_close-unmap.c
> @@ -8,7 +8,7 @@ int main()
> char buf[] = "mysemXXXXXX";
> if (!mktemp(buf)) return 1;
> // open twice
> - sem_t *sem = sem_open(buf, O_CREAT|O_EXCL, 0600);
> + sem_t *sem = sem_open(buf, O_CREAT|O_EXCL, 0600, 0);
> sem_open(buf, 0);
> sem_unlink(buf);
> // close once
> --
> 2.31.1
>
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.
