You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
I have observed that in ssh2-rs one of the unit tests has a tendency to deadlock on MacOS. What the test does is to issue a libssh2_channel_process_startup with "shell" as request, immediately followed by a libssh2_channel_close(). From what I can see is one of two things happening:
(note this is using non-blocking sockets):
A) no deadlock, but when close() waits for the remote SSH_MSG_CHANNEL_CLOSE message, it receives a SSH_MSG_CHANNEL_REQUEST with exit-signal instead, but close doesn't actually check what the received response was and moves on happily. The SSH_MSG_CHANNEL_CLOSE is received eventually as well, when the socket is wound down, but close() while waiting for it, never "saw" it.
B) deadlock: when close() waits for the remote SSH_MSG_CHANNEL_CLOSE message, it receives a EAGAIN error, and goes to socket_wait, where it will hang at poll() forever. Note that in this test, there is no configured timeout, so poll is called with timeout -1. But even if there was a timeout, things are clearly going really wrong.
adding a 100ms sleep between libssh2_channel_process_startup and libssh2_close() seems to NEVER cause a deadlock. I only observe this in a local test on Macs (server is also on the same local Mac). It also causes the MacOS github actions in ssh2-rs to hang on occasion. I cannot reproduce this on Linux or Windows.
To Reproduce
Steps to reproduce the behavior.
See above, I'll try to get better info.
Expected behavior
Not deadlock.
Version (please complete the following information):
MacOS 11 and 12, x86 and M1
libssh2 version: [e.g. 1.11.0]
crypto backend and version: N/A
Additional context
I realize this is a bit of a strange observation, and I acknowledge that perhaps the test in ssh2-rs is an anti-pattern, yet a deadlock should not occur.
The text was updated successfully, but these errors were encountered:
Describe the bug
I have observed that in ssh2-rs one of the unit tests has a tendency to deadlock on MacOS. What the test does is to issue a libssh2_channel_process_startup with "shell" as request, immediately followed by a libssh2_channel_close(). From what I can see is one of two things happening:
(note this is using non-blocking sockets):
A) no deadlock, but when close() waits for the remote SSH_MSG_CHANNEL_CLOSE message, it receives a SSH_MSG_CHANNEL_REQUEST with exit-signal instead, but close doesn't actually check what the received response was and moves on happily. The SSH_MSG_CHANNEL_CLOSE is received eventually as well, when the socket is wound down, but close() while waiting for it, never "saw" it.
B) deadlock: when close() waits for the remote SSH_MSG_CHANNEL_CLOSE message, it receives a EAGAIN error, and goes to socket_wait, where it will hang at poll() forever. Note that in this test, there is no configured timeout, so poll is called with timeout -1. But even if there was a timeout, things are clearly going really wrong.
adding a 100ms sleep between libssh2_channel_process_startup and libssh2_close() seems to NEVER cause a deadlock. I only observe this in a local test on Macs (server is also on the same local Mac). It also causes the MacOS github actions in ssh2-rs to hang on occasion. I cannot reproduce this on Linux or Windows.
To Reproduce
Steps to reproduce the behavior.
See above, I'll try to get better info.
Expected behavior
Not deadlock.
Version (please complete the following information):
Additional context
I realize this is a bit of a strange observation, and I acknowledge that perhaps the test in ssh2-rs is an anti-pattern, yet a deadlock should not occur.
The text was updated successfully, but these errors were encountered: