Exception thrown when invoking [_channel unsubscribe] #640
Comments
|
Sorry to hear this. @tcard @ricardopereira would one of you please look at this? |
mattheworiordan
added
the
bug
|
@tcard Adding a mutex lock should be enough, right? https://github.com/ably/ably-ios/blob/master/Source/ARTEventEmitter.m#L234-L248 |
|
@ricardopereira It is supposed to be in a mutex already. So somewhere must exist a method call on @liuzhen2008 Can you confirm which version of the library are you on? Those line numbers don't seem to correspond to a recent one. |
|
This is my podfile.lock We'll update the ably library as well. |
|
@liuzhen2008 That most likely will fix the issue, since we had widespread thread-safety bugs before 1.0.8. I'll tentatively mark this as closed, but please do open again if the issue persist. Thanks! |
|
@tcard We upgraded to ably 1.0.9 Podfile.lock as below: Still getting a crash occasionally. Try/catch doesn't even catch this time. |
|
@liuzhen2008 Unfortunately, I can't reproduce the problem. Does it happen in a production app? Could you tell us the app bundle identifier? |
|
@ricardopereira I am not sure with the "different queues" part. Is there a specific queue that i have to use when subscribing/unsubscribing from Ably? Would it be safer if i always execute subscribe/unsubcribe in main queue? com.charly.charlyUser is our app identifier. |
@liuzhen2008 Sorry. If you're using the library in different threads? Since we can't reproduce the problem, the only way we can debug this is by having the full stack trace of the exception. Do you have access to it and could you share it with us please? |
|
@ricardopereira I have full stack trace here. But go back to my question - would you say it is safer if i always run subscribe/unsubcribe in main queue? |
|
@liuzhen2008 Thanks a lot!
We changed the library to be thread safe so, but we might be missing some use cases. If you don't mind. Could you explain the |
|
@ricardopereira It was confusing naming on my part. It simply calls unsubscribe |
|
This is a tricky one. Basically, we try to ensure that all user code (calls to callbacks, mainly) runs in a different queue (the main queue, by default) than our internal queue, But in this case, the call to the user code happens because ARC deallocates an object when we remove the messages listener from the ARTEventEmitter, which happens to hold the last reference to such object, which causes its So @ricardopereira ARTEventEmitter's removeListener must always dispatch its operations to the user's queue (ie. |
|
@ricardopereira Also, that dispatch inside removeListener might need to be an async one. I think so. That will break a few tests, I expect. |
|
@tcard Yes, that makes sense. Thanks.
You say so because the user queue can be the main queue, right? |
|
@ricardopereira The user queue is the main queue by default. That ensures that user callbacks are run in the main thread, which is the only one that can do UI operations. That's not the problem. The problem is that
|
|
@liuzhen2008 I just realized we didn't get back to you on this; sorry for that. This should have been fixed by a7b67c6. We're going to do a release soon including that and other fixes. |
We sometimes experience an exception being thrown for [_channel unsubscribe];
The full stacktrace can be found below. This happens intermittently for us and we can't reliably reproduce the issue.
for now we just added try catch around [unsubscribe] hopefully it doesn't crash our users anymore.
The text was updated successfully, but these errors were encountered: