FoundationStream.cleanup() crashed with *** CFHash() called with NULL ***

[petraalm]

I'm using Starscream (3.0.2).
Happens when user returns in the app from background after awhile and the websocket is trying to reconnect. I believe this is a continuance of this "fixed" error.

[daltoniam]

Fixed was a poor choice of words. That issue only had a part of a backtrace and I was just guessing I fixed it because it was related to something I was working on. It didn't have anything useful to reproduce the error, but If you have a sample app or some code I could look at that would be helpful. Outside of that, I'm not sure what is happening as I there aren't any known issues with reconnecting.

[adrian-niculescu]

I'm also using Starscream 3.0.2 and encountered the same issue.

[colinfoko]

We're also just starting to notice this. However, we're using v2.1.1. I can let you know that we're getting it in our "low-bandwidth" testing. And, whether it's write or wrong ( a recent change on our end) is that our app immediately calls connect() from within the webSocketDidDisconnect delegate. I'm thinking we should hold offer for a bit and wait a few seconds before retrying.

[petraalm]

Interesting observation, I'm also calling connect() immediately within the webSocketDidDisconnect delegate on the first error, and then it goes in the backoff-mode retry.

[daltoniam]

3.0.3 has been released. It has some improvements/protections to help with this, but I'd make sure their aren't any race conditions when interacting with the WebSocket object. It is designed to have the public methods to be called from the same thread and that is normally what cases these crashes on cleanup. Also any sample code is greatly appreciated to help track down issues.

[petraalm]

I have some new information regarding this issue.
Once I've added a small delay (0.5 s) before reconnecting in webSocketDidDisconnect delegate, the cleanup crashes stopped appearing completely. I am still using version 3.0.2, haven't upgraded to 3.0.3.

So, to investigate further, I've tried to reproduce the crash. I've downloaded SimpleTest example and added following code to webSocketDidDisconnect method in ViewController.swift.

DispatchQueue.main.asyncAfter(deadline: .now()) {
    socket.connect()
}

It's the same code I was using in production with my app before adding delay.

I enabled Edge profile in Network Link Conditioner to simulate "low-bandwidth" mode. Test scenario was to open the app, connect to websocket, send the message, get the reply, and then lock the phone, unlock and immediately click on Write Text bar button.

Even though I was not able to reproduce the crash, I was able to freeze the app completely -- app would be stuck on waiting in some queue on main thread. Here is the screenshot.

I managed to catch it quite few times, but still, not that often.

Then I added a small delay:

DispatchQueue.main.asyncAfter(deadline: .now() + 0.5) {
    socket.connect()
}

I somehow managed to reproduce the similar freeze, but only once, although I did try many, many times. This was the stack:

Interestingly, I looked up what was happening in Thread 60:

It appears that in method FoundationStream.write(data:) outStream was something, and outputStream was nil.

That would be all.

[daltoniam]

Nice write up @petraalm! 3.0.4 has been released which I think such fix the issue with the freezing. Thanks again for the information.

P.S. I just explain some information about calling connect() from webSocketDidDisconnect in #415 if you are curious.