Skip to content
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.

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

Fix crash caused by cleanup() being called from multiple threads #476

Closed
wants to merge 1 commit into from

Conversation

flagoworld
Copy link

If InputStream/OutputStream .close() or *SetDispatchQueue is called
from two threads at the same time, it will cause a crash. This adds a
lock to prevent the cleanup() method from executing concurrently. Once
the first one is complete, inputStream and outputStream and nil and so
simultaneous attempts to cleanup() become noops.

Is it possible that locking inside cleanup() has some unintended side-effects? Take a look at let me know. I am not as familiar with the codebase...

If InputStream/OutputStream .close() or *SetDispatchQueue is called
from two threads at the same time, it will cause a crash. This adds a
lock to prevent the cleanup() method from executing concurrently. Once
the first one is complete, inputStream and outputStream and nil and so
simultaneous attempts to cleanup() become noops.
@hamchapman
Copy link
Contributor

hamchapman commented Mar 9, 2018

@fassko or @flagoworld, have either of you tried this with any success, or is it a hunch that this could / should fix it? We've got quite a lot of reports of a similar looking crash

@@ -248,6 +250,8 @@ open class FoundationStream : NSObject, WSStream, StreamDelegate {
}

public func cleanup() {
cleanupMutex.lock()
Copy link

@shawnce shawnce Mar 9, 2018

Choose a reason for hiding this comment

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

The lock will need to be applied universally to protect access to the vars protected here or it won't help much. I would also use an NSRecursiveLock unless you can fully understand / constrain the calling model that exists.

Copy link
Author

Choose a reason for hiding this comment

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

I don't think recursive lock is necessary here, but I understand what you are saying about protecting all the variables that are used within the lock across the class. That said, so far in practice this has eliminated the crashes without issue. Provide a better implementation for Dalton so we can get a fix merged!

@flagoworld
Copy link
Author

@hamchapman
I have had no further crashes since making this change.

@daltoniam
Copy link
Owner

I spent some time to cleanup the multiple NSLock objects and also help with this issue. I release new version (3.0.5) that should have a fix for this. Let me know if that fixes it.

@daltoniam
Copy link
Owner

It's been a while and based on the thumbs up feedback, I'm gonna assume we fix this. Thanks again!

@daltoniam daltoniam closed this Jul 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants