Bug 15200 - Leaking UITableViewCells
Summary: Leaking UITableViewCells
Alias: None
Product: iOS
Classification: Xamarin
Component: Xamarin.iOS.dll ()
Version: 7.0.0.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2013-10-04 07:56 UTC by George Piva
Modified: 2016-05-24 20:20 UTC (History)
5 users (show)

Is this bug a regression?: ---
Last known good build:

Instruments results for my application memory leaks. (686.37 KB, image/tiff)
2013-10-04 07:56 UTC, George Piva
Demo app showing the leak (1.51 MB, application/zip)
2013-11-08 12:16 UTC, Keith Mulholland

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description George Piva 2013-10-04 07:56:26 UTC
Created attachment 5061 [details]
Instruments results for my application memory leaks.

I am facing UITableViewCells leaking inside my application and I suppose it is the same problem which is happening with the MT.D Sample project.

More information can be found at:

Finally, I am sending a screenshot of my application being profiled with Instruments attached to this post.

Looking to the screenshot, is my problem similar to the presented issue (#201)?

I cannot see who is holding my cells and also Instruments does not give me the issued line in code which was supposed to be generating those leaks (it gives me only some Assembly code reference instead).

Is it also happening with all others MT.D applications?

Comment 1 Sebastien Pouliot 2013-10-04 08:33:34 UTC
`UITableViewCell` are normally [1] re-used, i.e. cached by iOS. That makes it harder (than other types) to know if they are leaked (because their life time is not what you normally expect). The screenshot (here and on giithub) does not provide enough details to see if it's normal (or not).

Please attach a test case that clearly show cells are being leaked.

[1] if not then it's an application bug
Comment 2 George Piva 2013-10-04 08:49:48 UTC
Actually, the UITableViewCells are being reused during all lifecycle of a UITableViewController. The leaks are just appearing when I switch from one screen to another.

For instance:
UITableViewController A -> is reusing it cells, only 7 cells are instantiated; Then the user returns to the application main menu and the UITableViewController A gets garbage collected. The same happens with my elements but those 7 created and REUSED cells are still there in memory.

Now if I enter back into the same menu and a NEW INSTANCE of my UITableViewController A gets initialized, it will create more 7 cells which in fact will not be able to  get released in the future.

By doing this for multiple times, you are going to see lots of UITableViewCells leaking although they were always getting reused in the past.

It is also happening with the MT.D sample project. Try to open and close the `Assorted Elements` screen and take a look about how many leaked UITableViewCells are there.

I may be wrong, I am just trying to clarify the issue I am facing.

But supposing it is an application Bug, how can I find the problem if the Instruments are not showing me the issued line in code?

Thanks in advance.
Comment 3 Sebastien Pouliot 2013-10-04 09:03:59 UTC
That's why screenshots are not much helpful for such problems (you see there's something off, but you don't see what it can be) and why a self contained test case can be.

* we need to confirm that the UITableViewController gets disposed (managed side);
* we need to ensure it's (native) reference count reach 0 (it's the native side that does the caching);
* we need to ensure nothing else (managed or native) creates references to the cells themselves;
Comment 4 George Piva 2013-10-04 09:19:18 UTC
Understood Sebastien.

I am going to try to create a small test case project presenting the issue and
then I will post it here.

I was supposing that I was facing the same issue as the one contained in the
MT.D sample project because I developed my Elements/UITableViewCells using the
MT.D.MessageElement/MessageCell as references because I am developing a Chat

Just in case, if you figure it out what is happening with the MT.D sample
project, may you share the information here?

Finally, thank you for your initial support.
Comment 5 Eduardo Coelho 2013-10-04 10:00:04 UTC
I'm having the same issue here.
My entire application uses the 'Patterns for Creating UITableViewCells' recommended by Miguel de Icaza (http://tirania.org/monomac/archive/2011/Jan-18.html), which is:

DialogViewController subclass
|___ MonoTouch.Dialog Element subclass
       |___ UITableViewCell subclass
              |___ UIView subclass
                     |___ <other model and heavy objects>

My entire application is made of DialogViewControllers, which means all data it grabs from the internet and presents to the user is constantly retained in memory (never released) until the application crashes due to memory usage.
In Mono Profiler I can see that my DialogViewControllers and MonoTouch.Dialog Elements are 
properly released, however, since UITableViewCells aren't released all other model/heavy objects it holds aren't released either.

As George Piva said, tableviewcell re-use is fine. All visible cells in a given table view are properly re-used, but they are never released (if I create N table views, then I'll end up having N*visible cells in memory forever).

Looks like some other object is holding reference to the UITableViewCells. The MonoTouch.Dialog sample (https://github.com/migueldeicaza/MonoTouch.Dialog) already shows this problem. My problem is just bigger: my unreleased cells contains heavy data which causes my application to crash.
Comment 6 Keith Mulholland 2013-11-08 12:16:35 UTC
Created attachment 5371 [details]
Demo app showing the leak

I'm also seeing TableViewCell leaks.

Occurs when animating the cell add or remove using TableView.InsertRows and TableView.DeleteRows. The TableViewController and the DataSource are cleaning up correctly, but heap shot is showing leaked cells.

I've attached a sample project to demostrate.

- Load the sample app
- Click the button to load the table view controller
- Add a few cells
- Tap back to pop the tableview controller
- Take a snapshot in Heap Shot

SampleTableViewController and SampleTableViewSource are gone, but the cells are still SampleTableViewCell objects.
Comment 7 Keith Mulholland 2013-11-08 12:36:01 UTC
* SampleTableViewController and SampleTableViewSource are gone, but the SampleTableViewCell objects remain.
Comment 8 Keith Mulholland 2013-11-12 05:14:03 UTC
Only occurs on iOS 7.

Anyone find a workaround?
Comment 9 Rolf Bjarne Kvinge [MSFT] 2013-11-13 18:48:34 UTC
I can't reproduce any leaked cells (or any other object) with the provided sample from comment #6.

Note that iOS likes to cache stuff, so it's normal to have a few cells in memory at any given time. But no matter what I did I could not reproduce an unlimited growth in the number of live cells, every time I returned to the first view the number of live cells dropped too.
Comment 10 Sebastien Pouliot 2016-05-24 20:20:32 UTC
We have not received the requested information. If you are still experiencing this issue please provide all the requested information and re-open the bug report. Thanks!