on 2022/08/05 23:00, Darrick J. Wong wrote:
> On Thu, Aug 04, 2022 at 02:18:52PM +0800, Yang Xu wrote:
>> It seems I met libcap errno bug again when using libcap-2.48-4.el8.x86_64.
>> But this time, errno is EINVAL if c program link with lcap.
>> Lastest upstream libcap doesn't have bug and it should be backport bug.
>>
>> generic/478 will become not run because of this. To fix this that only
>> exists on some distributions, reset errno to zero.
>>
>> Signed-off-by: Yang Xu <xuyang2018.jy@xxxxxxxxxxx>
>> ---
>> src/t_ofd_locks.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/src/t_ofd_locks.c b/src/t_ofd_locks.c
>> index e3b15ddc..e77f2659 100644
>> --- a/src/t_ofd_locks.c
>> +++ b/src/t_ofd_locks.c
>> @@ -187,6 +187,8 @@ int main(int argc, char **argv)
>> struct sembuf sop;
>> int opt, ret, retry;
>>
>> + //avoid libcap errno bug
>> + errno = 0;
>
> What sets errno to EINVAL here? And what actually causes the program to
> exit with code 22?
>
> There aren't any library calls prior to this point, right? Or is this
> ... libpcap has some initcall that runs quietly in the background before
> main starts, so we enter main with errno==EINVAL, which then causes ...
> something else to break?
Yes,
#include <stdio.h>
#include <errno.h>
int main(int argc, char **argv)
{
printf("errno %d\n", errno);
return 0;
}
gcc test.c -lcap -o test
then run test, errno is EINVAL.
But upstream libcap is ok and it should be a backport bug on libcap
distribution version.
Best Regards
Yang Xu
>
> --D
>
>> while((opt = getopt(argc, argv, "sgrwo:l:PRWtFd")) != -1) {
>> switch(opt) {
>> case 's':
>> --
>> 2.27.0
>>
