#1706 Memory leaks in ListBoxImpl::Create?

[Chinh Nguyen]

In PlatCocoa.mm ListBoxImpl::Create(), there's a scroller, a tableView, a couple of tableColumns, and an autocomplete datasource that are created but I can't seem to find where they are released.

I personally haven't observed any leaks myself because I don't use autocomplete but I stumbled across this code when making sure that everywhere I use setDataSource:, I make sure to set the receiver's data source to nil before I destroy the data source.

[Neil Hodgson]

The window is destroyed in Window::Destroy and my assumption was that its views and the objects they own were destroyed then. Profile shows no leaks when autocompletion lists are shown and cancelled.

[Chinh Nguyen]

The window releases the views and the objects they own but that doesn't mean that they're destroyed then.

When you create a view, it's got a retainCount of 1. When you addSubview: the view to its parent, the parent retains the view which means the view now has a retainCount of 2. When the window is destroyed, it releases the view which means its retainCount is back down to 1 and thus not destroyed. You need to release the view after it's been added to its parent to prevent the leak. The same thing applies to the tableView and its tableColumns; they need to be released (tableView retains the tableColumns when you add them, scroller retains the tableView when you setDocumentView:).

The AutoCompletionDataSource is leaking because you have a weak reference to it using setDataSource:. Who releases it when the window is destroyed?

You can take care of the leaks by autoreleasing the scroller ([[scroller initWithFrame: scRect] autorelease]), the tableView, and the tableColumns. For the AutoCompletionDataSource, you'll need to assign an instance variable to it and release it it when the window is destroyed.

[Neil Hodgson]

A potential fix committed as [199572]. Its a little ugly as the code had to be moved around for type visibility.