@marianoabdala hi there Mariano,

We're seeing crashlogs similar to the one you posted.

May i ask you if you found anything that might be causing this?

Thanks in advance!,
Jorge

Hi @jleandroperez, sadly we didn't.

I was hoping for a reply from the repo's author but didn't get one.

@marianoabdala thanks for the quick reply!. I'll dig further, and will keep you posted!

@jleandroperez I appreciate it.

@marianoabdala i've just sent a Pull Request with a potential fix for this crash.

Please, let me know if it helps!. I've been unable to directly trigger this crash, so far.

Doing some housekeeping. Please reopen if still relevant

@mikelikespie i'm afraid this is still relevant. Thanks in advance!

@mikelikespie thanks for reopening sir 😄

I have continued to see these crashes, as well as other related issues. I believe I have a solution that should avoid all such issues.

I previously closed by SRWebSocket objects like this:

[self.websocket close];
self.websocket.delegate = nil; // I don't care about the result, just try to close :)
self.websocket = nil; // Or reassign to a different socket

What this means is that the socket will start to close but by the time it is finished ARC will have released the object so self gives EXC_BAD_ACCESS.
Although the crash itself is very hard to reproduce as mentioned by others, another side effect is that there are lots of memory leaks (see https://github.com/intercom/intercom-ios/issues/111). This makes sense, because the socket doesn't get a chance to clean up.

Rather than trying to add lots of safety checks, I suggest that a better solution is to eliminate the race condition entirely. i.e. Make sure your socket is strongly referenced until it fully closes.

I have put together a gist with a class that will patiently wait for your SRWebSocket to close. Here it is: https://gist.github.com/jtreanor/4c67d6cc7955fceb5ea1.

Now my socket closing looks like this:

[[SRWebSocketCloser sharedInstance] addWebSocket:self.websocket];
self.websocket = nil; // This is now safe because I know the socket will be retained

I feel like this behaviour isn't something that could be built into SocketRocket but I would love to hear anyone's thoughts on it.

Perhaps the best course of action is to clearly document that SRWebSocket objects should always be retained until fully closed (not ideal either because we all know people will miss it 😃).

I'm also seeing this crash many times a day.

@siberianisaev If you're having an issue with Intercom, it'd be great if you could add details here: https://github.com/intercom/intercom-ios/issues/124.

Should this be closed?

Several of our top crashes used to be in handleEvent, but they have disappeared since updating from 7373546 to b0aabde.

Thank you! ❤️

Pure awesomeness!! glad to hear that @michaelkirk !!!

:hug:

Glad to hear this. Indeed there was a lot of fixes in the recent month.

Anyone still experiencing crashes - please make sure you are running latest master and open a new issue.

so this fix is not in cocoapods 0.5.1? can not find this in 0.5.1

I have got this crash a lot of time in 0.5.1 version.

Same here

I saw the code of the fix for this crash: I think the crash can still happen
cause _scheduleCleanup and _cleanupSelfReference are called in some places without calling first to remove from run loop, on the input and output streams.
I suggest to include remove from run loop in the cleanup function, and after closing the streams, schedule another scheduleInRunLoop which then will call - dispatch_async(_workQueue, ^{
_selfRetain = nil;
});

this way we make sure that the last request in the run loop is just releasing the selfRetain, after all possible stream events occurred.

I meet the same problem, sometimes, it crashed at

while ([_runLoop runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]]) {

}

I have the same issues, do you know how to fix?