Starscream: [CRASH] CoreFoundation _inputStreamCallbackFunc

[bobbyrehm]

This is on version 3.1.0.

Here's the stack trace via Crashlytics:

Crashed: com.vluxe.starscream.websocket
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000edb473fd0

0 libobjc.A.dylib 0x1aadfb530 objc_msgSend + 16
1 libobjc.A.dylib 0x1aaddf22c -[NSObject respondsToSelector:] + 36
2 CoreFoundation 0x1abb8276c _inputStreamCallbackFunc + 56
3 CoreFoundation 0x1abbadbc8 _signalEventSync + 216
4 CoreFoundation 0x1abbadc28 ___signalEventQueue_block_invoke + 24
5 libdispatch.dylib 0x1ab648a38 _dispatch_call_block_and_release + 24
6 libdispatch.dylib 0x1ab6497d4 _dispatch_client_callout + 16
7 libdispatch.dylib 0x1ab5f2320 _dispatch_lane_serial_drain$VARIANT$mp + 592
8 libdispatch.dylib 0x1ab5f2e3c _dispatch_lane_invoke$VARIANT$mp + 428
9 libdispatch.dylib 0x1ab5fb4a8 _dispatch_workloop_worker_thread + 596
10 libsystem_pthread.dylib 0x1ab829114 _pthread_wqthread + 304
11 libsystem_pthread.dylib 0x1ab82bcd4 start_wqthread + 4

[arnold-plakolli]

Happening to me as well. Same stack trace

[rztrom]

I have this problem as well. Same stack trace

[bobbyrehm]

I'm still seeing this crash after reverting to 3.0.6.

[yan-zaitsev]

I see same crashes on 3.1.0

[OlehKulykov]

I'm also conforming the same crash & stack trace, crashing up to ~10-20 times per day. Version: 3.1.0

[fassko]

Dealing with these issues is pain in the ass. I hope soon we all can use URLSession Websocket implementation. :)

[daltoniam]

As @fassko said, these issue are tough to deal with and debug with nothing more than a small piece of a backtrace. 4.0.0 refactor how connection logic is handle and should make this specific error no longer relevant in he codebase. Please upgrade and see if that fixes the issue and open a new issue if any questions or concerns arise with the new version. Thanks!

[jaltreuter]

This crash became very frequent for my iOS 10 and 11 users when I updated Starscream from 3.0.5 to 4.0.0. Based on logs, there's a strong correlation between the socket disconnecting and this crash.

[nickoto]

I did a little bit of investigation into this issue. If the application releases the websocket instance before the disconnect is completed the FoundationTransport is released but it has not yet been stopped. So messages to its delegate will still get fired and will result in this crash.

I'm not sure what the _right_ solution is to the problem; however, deinit in FoundationTransport to do the right cleanup or ensuring that engine doesn't release the transport until it is finished stopping (the stop is currently async, and only weakly holds onto self in the completion handler).

Otherwise the client needs to wait until the socket has been completely closed before releasing its instance.

A simple test for this problem:

Connect a websocket and then...

        webSocket.delegate = nil
        webSocket.disconnect()
        webSocket = nil