Log in

[markSci5]

Thanks! Actually, I only started setting the session to nil after you suggested it in another one of my posts. It solved the crashing issues from that post but this one still persists.

[mjtitus]

We haven't had problems with unexpectedly receiving our own streams, but we have experienced (and previously reported via email) leaks of OTSession and OTPublisher after disconnecting from a session.

[don]

Based on server logs, it looks like you're not actually disconnecting from the session. You are potentially connecting to it twice, leaving a dangling OTPublisher instance laying around that is actually still streaming in the background.

This conclusion is based on your logs and what we're seeing:

Server Logs:

14:41:12,914 Controllers:0 Publishers:0 Subscribers:0 # New Session
14:41:15,176 Controllers:1 Publishers:0 Subscribers:0 # First Connection Joins Session
14:41:17,889 Controllers:1 Publishers:1 Subscribers:0 # First Connection Publishes
14:41:18,535 Controllers:2 Publishers:1 Subscribers:0 # Second Connection Joins Session <- I would think this is where your problem lays if this second connection is the same device
14:41:23,152 Controllers:2 Publishers:1 Subscribers:1 # Second Connection Subscribes to First Connection
14:41:23,796 Controllers:2 Publishers:2 Subscribers:1 # Someone publishes (Two Publishers now)
14:53:00,624 Controllers:2 Publishers:1 Subscribers:2 # Someone stops publishing, another subscribes
14:53:01,186 Controllers:2 Publishers:1 Subscribers:1 # Someone stops subscribing
14:53:05,930 Controllers:2 Publishers:1 Subscribers:0 # Someone stops subscribing
14:53:06,106 Controllers:2 Publishers:0 Subscribers:0 # Someone stops publishing
15:00:53,539 Controllers:1 Publishers:0 Subscribers:0 # Someone disconnects
15:22:31,985 Controllers:0 Publishers:0 Subscribers:0 # Last person disconnects

[markSci5]

So the previous OTSession and publisher was still remaining even though I thought I disconnected it properly. hmmmmmm

I've got a question, regarding sessionDidFail. I was assuming that if it was called, the session was already disconnected. Should I still call [session disconnect] after a session connection failure before reconnecting to that session? I haven't tested it yet, but perhaps this could be the reason?

@mjtitus

What were the scenarios were you found out that OTSession and OTPublisher were leaking? How did you fix it?

Thanks. I would appreciate any help.

[markSci5]

Also, I wanted to make sure I wasn't doing anything special that created retain cycles, so I tested the sample OpenTokBasic iOS app and I've found that it too was leaking instances of OTSession and OTPublisher, even after I disconnected. Although, I didn't receive any stream from my own device, I'm guessing the leaking OTSessions and OTPublishers are issues that haven't been fully resolved yet?

[markSci5]

Ok, this is what I found out.

I think this bug happens if I automatically connect during the sessionDidDisconnect callback.

Code: Select all

- (void)sessionDidDisconnect:(OTSession*)session
{
    ...
    _session = nil;
    [self doConnect];
}


I've tried it out on the OpenTokBasic sample app and I could replicate the bug there which means I wasn't doing anything else weird in my code aside from immediately connecting after the session was disconnected. I added this automatic reconnection function because I wanted the user to be able to immediately connect to a different session if he wanted to, without having to go through the hassle of tapping a disconnect button.

I don't know if this is a matter of timing issues, but intuitively, the session should be completely disconnected already by the time sessionDidDisconnect is called or even after I've set my OTSession instance to false. I guess this bug happening just proves this isn't the case as of now.

@don or @mjtitus

Just wanted to know your opinion on this and if I'm on the right track. If this is the case, then I may need to create a separate disconnect button on my app.

[don]

Sorry for the delay on this one, long weekend got in the way there. I'll be digging into this one today. I'll report back with my findings.

[don]

I am still unable to reproduce this issue.

I just did a git clone of the OpenTokHelloWorld project and changed the following two methods:

Code: Select all

- (void)sessionDidDisconnect:(OTSession*)session
{
    NSString* alertMessage = [NSString stringWithFormat:@"Session disconnected: (%@)", session.sessionId];
    NSLog(@"sessionDidDisconnect (%@)", alertMessage);
    [self showAlert:alertMessage];
   
    _session = nil;
    _session = [[OTSession alloc] initWithSessionId:kSessionId
                                           delegate:self];
    [self doConnect];
}


I'm automatically disconnecting after 10 seconds of being connected to a session (to invoke the sessionDidDisconnect: selector):

Code: Select all

- (void)sessionDidConnect:(OTSession*)session
{
    NSLog(@"sessionDidConnect (%@)", session.sessionId);
    [self doPublish];
   
    int64_t delayInSeconds = 10.0;
    dispatch_time_t popTime = dispatch_time(DISPATCH_TIME_NOW, delayInSeconds * NSEC_PER_SEC);
    dispatch_after(popTime, dispatch_get_main_queue(), ^(void){
        [_session disconnect];
    });
}


I followed up by running it through the Leaks profiler for about 20 cycles and I'm not seeing any of my OTPublisher or OTSession objects getting leaked (albeit there are a few minor leaks that should be cleaned up in the next release). Are you sure you don't have a strong reference to one of these objects (OTSession or OTPublisher) somewhere in your code?

If you want, please attach the HelloWorld project you modified to reproduce this behavior and I'll see what I can find from that.

To be clear:

I'm using the OpenTok iOS SDK from our GitHub page: https://github.com/opentok/opentok-ios-sdk
with the OpenTokHelloWorld example: https://github.com/opentok/OpenTok-iOS-Hello-World

You can download them both at the same time by running:

Code: Select all

git clone git@github.com:opentok/OpenTok-iOS-Hello-World.git --recursive

[markSci5]

Ok, I don't know what I happened but I can't replicate the bug anymore on the sample app (I was using opentok-basic-tutorial rather than opentok-helloworld project). Perhaps I was too hasty in posting my findings or I just messed up my previous testing. I have implemented a manual disconnect button on my app though and I haven't experienced any problems again so far. I'll have to wait and see.

BUT, I can replicate the memory leaks of OTSession and OTPublisher on the opentok-helloworld project. Although I guess "abandoned memory" is the correct term since they won't show up on the leaks instruments but you can see multiple living instances on the allocations list.

I've posted a screenshot after running opentok-helloworld for a minute with your modifications and its clear that the OTSession and OTPublisher instances won't die even after disconnection. Now, I'm not sure if this is supposed to be normal, but I'm guessing it's not supposed to work this way ?

I've also done some heapshot analysis using the opentok-basic project. I marked a heapshot after everytime I connected and disconnected and I found 1 instance each of OTSession and OTPublisher on every heapshot meaning they weren't destroyed after disconnecting. I think this a clearer sign of memory leaking rather than the leaks instrument.

As of now, I'm not having any problems, but I am worried about any weird behavior this may cause in the future. And I can't be sure that any bug I experience with tokbox from now on may or may not be related to these "memory leaks". Is it alright for me to just ignore this for now?

[don]

Glad your original problem seems to have cleared up. As for the object leaks, I'm in the process of going through all of those right now and they should be cleaned up for our next release (sometime in the next couple weeks). You can safely ignore these for now, assuming you're not connecting/disconnecting to sessions more than a reasonable amount of times, the leaks you're seeing are pretty small (though annoying I do agree).

Keep an eye on the GitHub page for updates to the SDK