Create thread in shell finalizer #339
Conversation
The following call chain was observed: 1. Cmd.close_shell or Powershell.close_shell 2. HttpTransport#send_request 3. HTTPClient#post And HTTPClient#post internally calls Mutex#synchronize, which raises ThreadError if called from a finalizer. Although the behavior is not documented, it makes sense as a finalizer can be called in a block passed to Mutex#synchronize, and calling Mutex#syncrhonize again for the same mutex in the finalizer can lead to deadlock. Create a thread in the shell finalizer and do everything in the thread to avoid problems with Mutex#synchronize.
|
This is also failing with the same error - |
We can do nothing when the main thread is already dead. c.f., https://bugs.ruby-lang.org/issues/4992 |
|
Is this specific with any ruby version. We started facing this after updating ruby to 3.1 |
No, but Ruby is free to change the timing to run finalizers so it's possible to see errors with an arbitrary condition. Updating Ruby may or may not break code that relies on the finalizer. |
|
Thanks . Hey , I just debug this further and found the the main thread is not in terminated stated, its in sleep state. |
That's strange. In any case, there is nothing we can do on the WinRM side. You need to debug Ruby. |
|
Is this still useful to merge? |
Yes, the situation has not changed since I opened the pull request. |
|
thanks |
|
Just noting here that the test suite passes with this merged, but it's now spamming the logs (see below for a snippet) It seems rspec doesn't like this change, although I don't know whether this indicates an actual issue or not. At the very least it requires further investigation to ensure that the tests are still valid -- possibly some expectations are now inadvertently running in a different thread, which may not assert correctly. |
|
@pcai The logs imply shells are not closed. Shells created with mocks must be closed before tests finish. |
The following call chain was observed:
Cmd.close_shellorPowershell.close_shellHttpTransport#send_requestHTTPClient#postAnd
HTTPClient#postinternally callsMutex#synchronize, which raisesThreadErrorif called from a finalizer. Although the behavior is not documented, it makes sense as a finalizer can be called in a block passed toMutex#synchronize, and callingMutex#syncrhonizeagain for the same mutex in the finalizer can lead to deadlock.Create a thread in the shell finalizer and do everything in the thread to avoid problems with
Mutex#synchronize.