Crashes in 1.1.1

[nuclearace]

In the latest version I've noticed some crashes after the delegate is released. It doesn't happen all the time, but it happens pretty often. Not sure if I'm doing something crazy.

Test project: https://github.com/nuclearace/WebSocketCrash

[nuclearace]

I believe you need to add

deinit {
    outputStream?.close()
    inputStream?.close()
}

[nuclearace]

Closing the streams seems to work most of the time, but there's still the occasional crash

[nuclearace]

Actually it seems like if there's a lot of activity going on with the socket when it's being deinit it's more likely to crash

[mattlilek]

I just noticed this when upgrading my project to 1.1.1. If you run with zombies enabled, you get:
*** -[Starscream.WebSocket respondsToSelector:]: message sent to deallocated instance 0x1ff86bdc0

I'm not sure about the close() calls you mention @nuclearace, but I think the delegate for each of the streams need to be cleared. NSStream's delegate is unowned(unsafe) not weak so they're left dangling, just like in the Obj-C days. At least that consistently fixed the crashes for my project.

[nuclearace]

@mattlilek even setting the delegates to nil seems to cause a crash occasionally.

[daltoniam]

yeah this is a weird one (and I didn't see it when I ran my Autobahn test project, really strange). I ran the profiler and it looks like it is still getting delegate messages from the CFStreams which obviously is a problem if the object has been deallocated. Let me know if the fixes works and I will do a new version.

[nuclearace]

Still seeing some crashes

[daltoniam]

hmmm, ok I checked in another possible fix. I am not able to reproduce the issue with the same node server and example app, let me know if that resolve it.

[nuclearace]

That fixes most of the crashes, but I still get that occasional crash that looks like this

[nuclearace]

It's much less common than the other ones though, and certainly a race condition

[daltoniam]

ok good to know. We will probably have to add some protection before scheduling the to queue if the WebSocket has been deallocated. I will try to do that tomorrow if time permits.

[daltoniam]

I am trying to reproduce that last crash with the test app + node server, is there anything I can do to modify the example to trigger the crash more frequently? So far I haven't been able to reproduce it after multiple tries.