Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 18 Feb 2020 22:07:54 -0600
From: Bobby Bingham <>
Subject: Re: race condition in sem_wait

Sebastian Gottschall <> writes:

> Hello
> i discovered recently a race condition while playing with threads and
> sem_wait/sem_post
> sem_wait may fail with errno set EAGAIN which is not valid since only
> sem_trywait is able to set that errno code.
> this was causing a bug with a later select() and accept() which failed
> since accept does not work if errno is set to EAGAIN.

Whether select/accept work or not should not be impacted by any existing
value in errno.

> from my point of view the bug is in sem_timedwait.c
>         if (!sem_trywait(sem)) return 0;
>         int spins = 100;
>         while (spins-- && sem->__val[0] <= 0 && !sem->__val[1]) a_spin();
>         while (sem_trywait(sem)) {
> the fist sem_trywait will fail with -1 and sets EAGAIN. but the second
> sem_trywait will not fail and does return 0. the problem now is that
> errno is still present and not reset.
> this may cause if sem_post is called from a second thread on the same
> semaphore.
> of course the same bug affects sem_timedwait itself.
> so i assume sem_wait is not thread safe which is bad and is not follow
> the posix specification

To quote POSIX [1]:

    The value of errno should only be examined when it is indicated to
    be valid by a function's return value. [...] The setting of errno
    after a successful call to a function is unspecified unless the
    description of that function specifies that errno shall not be

If sem_wait() returns zero, then the value in errno after the call
returns is not meaningful in any way.


> or am i wrong here?
> Sebastian


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.