Socket.io-client-swift: SocketEnginePollable Crash Sometimes

[Abreu0101]

Sometimes the app crash in the class (SocketEnginePollable), in the next method,

doRequest(req:NSURLRequest, withCallback callback: (NSData?, NSURLResponse?, NSError?) -> Void)

Specifically when calling:
session?.dataTaskWithRequest(req, completionHandler: callback).resume().

I'm using version 5.5.0, the last part of the log that I receive:

Log
2016-04-26 17:14:14.824 Logic[479:93592] *** Terminating app due to uncaught exception 'NSGenericException', reason: 'Task created in a session that has been invalidated' *** First throw call stack: (0x2293e2eb 0x2210adff 0x22e3f77d 0x22e40463 0x10e168 0x10db58 0x10d9ec 0x18acf8 0x18cb38 0x18cee4 0x1121b4 0x10f36c 0x231040 0x22aecbf 0x22b95c3 0x22b1efb 0x22baab7 0x22ba909 0x22674e0d 0x226749fc) libc++abi.dylib: terminating with uncaught exception of type NSException 2016-04-26 17:14:14.826 Logic[479:93566] LOG SocketEngine: Got message: 0{"sid":"_towWQV4p66lC-UeAAVf","upgrades":["websocket"],"pingInterval":25000,"pingTimeout":60000} 2016-04-26 17:14:14.823 Logic[479:93918] LOG SocketEngine: Got message: 40 2016-04-26 17:14:14.854 Logic[479:92712] LOG SocketIOClient: Disconnected: Ping timeout 2016-04-26 17:14:14.854 Logic[479:92712] LOG SocketEngine: Engine is being closed. 2016-04-26 17:14:14.855 Logic[479:92712] LOG SocketEnginePolling: Created POST string: 1:1

[nuclearace]

Does it still happen in 6.1.0? My guess is doRequest isn't being called from the right dispatch_queue

[nuclearace]

@MishraVikas1 Do you have any more on this? Like what request is causing it?

[MishraVikas1]

Its happening in 6.1.0 as well. In SocketEngine.swift, there is a method named disconnect() which is calling do request method.
Crash only occurs when network keeps fluctuating.

[nuclearace]

That's weird because doRequest has a check against invalidation.

[aligermiyanoglu]

Hi,

I am experiencing similar issue, you can check on:
http://crashes.to/s/b20e5c6a150

Best

[px751]

Same problem here ! Here is the log if needed. Please ask if you need more infos

SocketIOSwift Version : 6.1.0

[nuclearace]

@px751 When does this happen? Theoretically doRequest should check against invalidation. So my guess is something is invalidating on another queue. Also the line numbers in that log are a little wonky I think.

[px751]

I dont really know, it seems to be when the app disconnects...
Here are the details : http://crashes.to/s/77c635c5d77
I dont really know how to reproduce this problem but we have more that 100 users who are impacted, almost all on iOS 9.

I call the SocketIO diconnect function when the user leaves the app, maybe this comes from there, the app is kind of already in background and the background task crashes (?)

[px751]

@nuclearace Please tell me when I can make this issues private, I dont like having these info on a free access on a application in production :)

[px751]

I the [socketClient diconnect] this in the "- (void)applicationDidEnterBackground:(UIApplication *)application" function, this class is a singelton

Just before I stop the localisation service, and save the user class, but I dont think this is linked

Oh, and I dont know if this information is important, but my app is in Obj-c, not swift

FYI, the server is using SocketIO version ~1.3.2

[px751]

I've tries to debug but It seems that the function is not called when the socket io disconnects, but only at connexion or re-connexion, I am going to try to crash the server and see if this comes from this part

[nuclearace]

Yeah, this one might be tough to debug

[px751]

Let me know if you have a clue so I can test

[nuclearace]

Well something is calling stopPolling() after this code path gets past the check. Are you adding a new socket after you call disconnect?

[nuclearace]

I do see some weirdness in the websocket disconnect logic that I'll have to look into to.

[nuclearace]

If you can reproduce locally and want to test a change, change https://github.com/socketio/socket.io-client-swift/blob/master/Source/SocketEngine.swift#L283 to

if closed || !connected {
    postSendClose(nil, nil, nil)
    return
}

I'm always hesitant to change things dealing with the connection/disconnection since it's rather squishy.

[nuclearace]

You can also test the latest development branch

[paulcarpenter]

Also seeing this intermediately for the first time after using the library for a few weeks. It does seem to show up with a user who has notoriously spotty network connections on his phone. I'll give the latest development branch a try, and follow up if I see it again.

[aligermiyanoglu]

@paulcarpenter you could be right about spotty network connections guess. Our users also have lagy network conditions

[hifall]

I am also seeing the same issue. And here is the call stack:

Socket error!
Socket error!
Socket reconnecting...
Socket attempting to reconnect...
2016-07-10 18:15:17.357 StoreExample[40511:5869820] Attempted to create a task in a session that has been invalidated
2016-07-10 18:15:17.365 StoreExample[40511:5869820] * Terminating app due to uncaught exception 'NSGenericException', reason: 'Task created in a session that has been invalidated'
** First throw call stack:
(
0 CoreFoundation 0x0000000110454d85 *exceptionPreprocess + 165
1 libobjc.A.dylib 0x0000000112a9adeb objc_exception_throw + 48
2 CFNetwork 0x00000001141348ed -[__NSURLSessionLocal taskForClass:request:uploadFile:bodyData:completion:] + 386
3 CFNetwork 0x0000000114135960 -[__NSURLSessionLocal dataTaskForRequest:completion:] + 77
4 ClientLib 0x000000010fb30963 _TFE8ClientLibPS_20SocketEnginePollable9doRequestfTCSo12NSURLRequest12withCallbackFTGSqCSo6NSData_GSqCSo13NSURLResponse_GSqCSo7NSError__T__T_ + 1331
5 ClientLib 0x000000010fb30418 _TFE8ClientLibPS_20SocketEnginePollable10doLongPollfCSo12NSURLRequestT_ + 232
6 ClientLib 0x000000010f990910 _TFFC8ClientLib12SocketEngine7connectFT_T_U_FT_T_ + 80
7 ClientLib 0x000000010f990957 _TTRXFo__dT__XFdCb__dT + 39
8 libdispatch.dylib 0x0000000113ba8d9d _dispatch_call_block_and_release + 12
9 libdispatch.dylib 0x0000000113bc93eb _dispatch_client_callout + 8
10 libdispatch.dylib 0x0000000113baf82c _dispatch_queue_drain + 2215
11 libdispatch.dylib 0x0000000113baed4d _dispatch_queue_invoke + 601
12 libdispatch.dylib 0x0000000113bb1996 _dispatch_root_queue_drain + 1420
13 libdispatch.dylib 0x0000000113bb1405 _dispatch_worker_thread3 + 111
14 libsystem_pthread.dylib 0x0000000113f064de _pthread_wqthread + 1129
15 libsystem_pthread.dylib 0x0000000113f04341 start_wqthread + 13
)
libc++abi.dylib: terminating with uncaught exception of type NSException
(lldb)

This happened after a socket error and it tried to reconnect.

[hifall]

@nuclearace, in order to test your fix, should I change SocketEngine.swift like this?

public func disconnect(reason: String) {
if closed || !connected {
postSendClose(nil, nil, nil)
return
}
guard connected else { return closeOutEngine(reason) }
........

[hifall]

This happened in 6.1.4.

[paulcarpenter]

Also still happening in 6.1.4 for me. As our user base is growing, we're starting to see lots of these show up (and we still don't have _that_ many users). Going to try @nuclearace's drop-in fix in our beta builds, but a real investigation of this would be great.

EDIT 2 minutes later: postSendClose is not a method in 6.1.4.

[nuclearace]

It would be https://github.com/socketio/socket.io-client-swift/blob/master/Source/SocketEngine.swift#L289

[nuclearace]

I still haven't been able to reproduce this. If anyone could find a way to produce it with like 90% reproducibility that'd be helpful.

[hifall]

More info on this, for the purpose of potentially easier reproduction:
I saw this on a simulated iPhone 5s, Xcode 7.3.1, OS X El Capitan. It was in a not-so-stable network, with VPN switched on/off from time to time.

Although that was the environment where it happened, it doesn't necessarily mean that any of the factors above contributes to the occurrence of the bug. I just saw the issue a couple of times, so I have not found a consistent way to reproduce this.

Although from personal experience, this doesn't happen every day, but as @paulcarpenter says, if your user base grows, this issue will happen more. And when it happens, it crashes the whole app, which is not good. So I support for some serious investigations here.

[hifall]

@nuclearace, as mentioned by @paulcarpenter, postSendClose is not a method in 6.1.4. So how to test your fix (if the offer still valid) now?

[paulcarpenter]

I tried setting the session variable to nil explicitly in public func stopPolling() but I'm still seeing the error and getting the crash reports. I can't find any other method in the library that is invalidating the session; and I can't find any information that says how and when the system might invalidate the session silently.

Any more help we can get with this?

[Arnadus]

I don't know if it can help but I've been able to reproduce it quite often (100% time after 15-20 seconds running) by connecting and disconnecting the socket in a tiny amount of time.

Check the example below, just call the "doCrash" method.

class CrashTest {

    var socket:SocketIOClient!
    var url : String = "http://www.example.com" //TO BE CHANGED

    init() {
        socket = SocketIOClient(socketURL: NSURL(string: url)!, options: [.Log(true)])
        socket.reconnects = false
    }

    // to be called when socket is ready
    func start(){
        NSTimer.scheduledTimerWithTimeInterval(0.01, target: self, selector: #selector(check), userInfo: nil, repeats: true)
    }

    @objc func check() {
        dispatch_async(dispatch_get_main_queue(), {
            if self.socket.status != .NotConnected{
                self.socket.disconnect()
            }
            self.socket.connect()


        })
    }

    static func doCrash(){
        let crashTest = CrashTest()
        crashTest.start()
    }
}

[nuclearace]

@Arnadus Many thanks, I see it now

[nuclearace]

Should be fixed in development

[paulcarpenter]

Unfortunately, this just came back from one of our testers. Seems to be much less common now, but not entirely gone. In the swift3 branch, it throws on line 105 of SocketEnginePollable, on the same old session?.dataTaskWithRequest(req, completionHandler: callback).resume() and Task created in a session that has been invalidated

[nuclearace]

I'm not sure how much more I can do. Do you have a reliable way to reproduce?

[rehsals]

I can confirm that this crash still persists on 6.1.6. But it happens really rare when the app goes into background.

[therudite]

Yes, I get it 1 out of 5 times.

[Lwdthe1]

Swift 2.3 is happening the same issue apparently. disconnect is called from AppDelegate's applicationDidEnterBackground method. Here's the log and error stack:

Excuse the do{} catch{} blocks. I was trying to debug.

[daicaga]

I'm using
pod 'Socket.IO-Client-Swift', '~> 7.0.3'
and it happened as well.

[laeroah]

Any updates on this issue? We are still seeing it in version 8.2.0.

[nuclearace]

I haven't been able to reproduce, if someone can provide a sample project, that would help.

[tahirbinpasha]

did anyone found the solution ?