Reference count monitoring

About

A bug in reference counting can introduce a huge memory-leak, an ugly crash in higher programming languages that utilize garbage collection or total confusion for the developer that will use the tinymail framework. Leading to incompatible APIs where in one version you have to and in another version you don't have to unreference an instance.

This is unwanted. Of course.

The rule is that tinymail aims to be reference counting neutral. This means that references are rather added than borrowed. And if borrowed, it's specified that reparenting is happening.

For example when you add an item to a list and you destroy the list, then the item isn't destroyed because you still have the first reference that came from the object construction.

Internally, however, if you ask for a list of headers. The reference count of each item will be one. That's because reparenting happened: the list became the owner of the item. This means that if you destroy the list, the item will be unreferenced (because an owner dies). If that means that the item reached the zero refcount, it will indeed be destroyed. This is the typical case of course.

It's very important for tinymail to get it right. Huge memory leaks are of course the result of not getting it right.

How you can help

You can help by testing, testing and again testing whether tinymail gets it right.

Unit tests?

The maintainer of tinymail (Philip) hasn't yet found a solid method for testing reference counting problems using unit tests. It's probably very possible, so he's interested in your input on this.

Memory testing tinymail

More information about memory testing tinymail can be found on this page.