CBLListener retaining CBL_RunLoopServer so both never get freed.

[brendand]

I have a TFDatabaseDocument class that holds on to a CBLListener and a CBLManager instance.

I create the CBLListener like this:

self.syncListener = [[CBLListener alloc] initWithManager:self.couchManager port:0];
self.syncListener.delegate = self;

When I close my TFDatabaseDocument class, I do these things in a stop method I call before the document is closed:

[self.syncListener stop];
self.syncListener.delegate = nil;
self.syncListener = nil;

I also stop the CBLManager and nil it out too, just to be sure.

I can confirm that dealloc is definitely being called when my TFDatabaseDocument class closes and it's deallocated properly.

However, when I use the memory graph debugger in Xcode, I see that the CouchbaseLite CBL_RunLoopServer and a bunch of classes in CouchbaseLiteListener are still in memory.

Here's what the memory graph debugger shows in Xcode 9:

I tested to see what happens when I don't instantiate a CBLListener and I find that CouchbaseLite CBL_RunLoopServer no longer appears in the Xcode 9 memory debugger when I release my class.

So it seems to me that when you instantiate a listener, it's retaining the CBL_RunLoopServer even when you deallocate your class that holds the listener. And this prevents the listener from freeing up all of its resources and the CBL_RunLoopServer.

I've tested this both on macOS 10.13 and iOS 11. Same results on both.

Is there another way I should be trying to clear out the CBLListener?

---

• Version: 1.4.1
• Client OS: macOS 10.13 High Sierra and iOS 11.
• Server: n/a

[pasin]

From the graph, I could see the circular references between CBLHTTPListener and CBLHTTPServer. Probably one of them needs to be weak reference.

[brendand]

And I just found out the purple [!] indicate leaks.

[brendand]

As a test I set the listener on CBLHTTPConnection.h to weak:

@property (weak) CBLListener* listener;

That improved things so now the CBL_RunLoopServer no longer exists after closing. But a couple of classes in the CouchbaseLiteListener are still hanging around. Namely CBL_DDLoggerNode and CBL_MYDDLogger.

That was just a test though to see what would happen. I'm sure you'll have a better fix.

[brendand]

There might be other places that it's not letting go.

So even though I deallocate the place where I originally created the CBLManager, I get these leaks in the CouchbaseLite framework here after my object is gone.

[brendand]

If I don't startup the listener, then the CouchbaseLite framework classes properly get deallocated when I close my file.

[brendand]

Adding this code to remove the loggers in CBLHTTPListener helps to free up the listener too:

- (void)dealloc {
	[DDLog removeAllLoggers];
}

[brendand]

Perhaps going a bit ballistic to try and resolve this issue, I've been doing more experimentation with cleaning up things:

CBLSyncListener.m

Changed CBLManager *_manager to:

__weak CBLManager* _manager;

added these to dealloc:

	[_netService stop];
	_netService.delegate = nil;
	_manager = nil;
	_facade = nil;
	_queue = nil;
	[_handlers removeAllObjects];

CBLManager.m

added to close method:

[_replications removeAllObjects];

CBLHTTPConnection.h

changed:

@property (retain) CBLListener* listener;
@property (retain) CBL_Server* cblServer;

to:

@property (weak) CBLListener* listener;
@property (weak) CBL_Server* cblServer;

So maybe overkill in some spots. But it seems to get the job done.

[pasin]

• (void)dealloc {
  [DDLog removeAllLoggers];
  }

This might not be correct for example if starting 2 replicators. Also if you don't enable Listener logging, you will not see the DD_Logger objects - I guessed your production release will not have the Listener logging enabled.

[pasin]

Somehow I don't see the replicator leaks as you mentioned in #1921 (comment). Also it is a good idea to create a separate ticket for replicator leak.

[pasin]

@brendand I did a minimum fix. I don't fix the Logger issue as the CBL_MYDDLogger is created once for the CBLHTTPListener class, and it will be created only when the Listener logging is enabled. For the Replicator leaks issue, please create a new ticket.