[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5ff92ac3-a5e0-b97e-4205-f5d62c98b389@disroot.org>
Date: Tue, 27 Apr 2021 17:49:45 -0300
From: Érico Nogueira <ericonr@...root.org>
To: musl@...ts.openwall.com
Subject: Re: Re: libc-test issue with sem_close
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.
>
> Note: for musl master I ran it as
>
> /path/muslrepo/lib/libc.so /path/libc-tests/.../sem_close-unmap.exe
>
> Cheers,
> Érico
View attachment "0001-fix-sem_close-regression-test.patch" of type "text/x-patch" (1133 bytes)
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.
