Skip to content

PYTHON-2334: Fix gevent race condition #472

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jul 29, 2020
Merged

PYTHON-2334: Fix gevent race condition #472

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
4418e5f
If gevent raises a Timeout during self.lock acquisition, a _socket_se…
tyler-willey Jul 24, 2020
921e658
Using with will release the condition even on exception being raised
tyler-willey Jul 27, 2020
918ad32
Change to use flag so that the same exception handling is used
tyler-willey Jul 29, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 9 additions & 4 deletions pymongo/pool.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1257,12 +1257,15 @@ def _get_socket(self, all_credentials):
if not self._socket_semaphore.acquire(
True, self.opts.wait_queue_timeout):
self._raise_wait_queue_timeout()
with self.lock:
self.active_sockets += 1

# We've now acquired the semaphore and must release it on error.
sock_info = None
incremented = False
try:
with self.lock:
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If gevent raises on the acquire here, self._socket_semaphore's lock will be permanently decremented.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be simpler to move the active_sockets modification down below inside the existing try/except:

# We've now acquired the semaphore and must release it on error.
sock_info = None
try:
    with self.lock:
        self.active_sockets += 1
    while sock_info is None:...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought of that, however the second try/except block will decrement the active sockets if an exception is raised.

If you raise within the first with self.lock, you will not have first incremented active_sockets, so you will end up permanently decreasing active_sockets.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. What about adding a flag:

# We've now acquired the semaphore and must release it on error.
sock_info = None
incremented = False
try:
    with self.lock:
        self.active_sockets += 1
        incremented = True
    while sock_info is None:...
except Exception:
    if sock_info:
        # We checked out a socket but authentication failed.	                
        sock_info.close_socket(ConnectionClosedReason.ERROR)
    self._socket_semaphore.release()
    if incremented:
        with self.lock:
            self.active_sockets -= 1

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would work... Should I add that?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated, seems to still work

self.active_sockets += 1
incremented = True

while sock_info is None:
try:
with self.lock:
Expand All @@ -1279,8 +1282,10 @@ def _get_socket(self, all_credentials):
# We checked out a socket but authentication failed.
sock_info.close_socket(ConnectionClosedReason.ERROR)
self._socket_semaphore.release()
with self.lock:
self.active_sockets -= 1

if incremented:
with self.lock:
self.active_sockets -= 1

if self.enabled_for_cmap:
self.opts.event_listeners.publish_connection_check_out_failed(
Expand Down
31 changes: 15 additions & 16 deletions pymongo/thread_util.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -40,22 +40,21 @@ def acquire(self, blocking=True, timeout=None):
raise ValueError("can't specify timeout for non-blocking acquire")
rc = False
endtime = None
self._cond.acquire()
while self._value == 0:
if not blocking:
break
if timeout is not None:
if endtime is None:
endtime = _time() + timeout
else:
timeout = endtime - _time()
if timeout <= 0:
break
self._cond.wait(timeout)
else:
self._value = self._value - 1
rc = True
self._cond.release()
with self._cond:
while self._value == 0:
if not blocking:
break
if timeout is not None:
if endtime is None:
endtime = _time() + timeout
else:
timeout = endtime - _time()
if timeout <= 0:
break
self._cond.wait(timeout)
Copy link
Contributor Author

@TylerWilley TylerWilley Jul 27, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will release, and re-lock self._cond

Condition has 2 acquires in it, If _waiter.acquire() raises, Condition will re-acquire in the finally clause.

If _acquire_restore raises, then Condition won't re-acquire and a double-release is possible. I can't think of a good way to solve that. One possible solution would be to update gevent to monkey patch Condition with a version that guarantees self._lock re-acquisition prior to raising. A double release here is somewhat less concerning though, as it would only cause one waiter to hang until the next notify, instead of leaking a lock.

Reference:
https://github.com/python/cpython/blob/v3.6.9/Lib/threading.py#L295-L304

else:
self._value = self._value - 1
rc = True
return rc

__enter__ = acquire
Expand Down