Overview

The article is to help identify memory leaks of EiffelStudio and present one way of, to the maximum extend, getting rid of them. For now, with the tool in hand, it is difficult to guarantee that EiffelStudio is memory leak free. Every incorrect programmed operation could cause a leak, but not any operation we can check. One of the basic checks is opening a new window and close it, ensuring there is no leak by this operation. We call this OC operation. Though we can only do the basic to ensure what we are able to, this help one learn at programming in Eiffel how memory leak occurs and how to prevent from happening.

What is memory leak

Definition

Memory leaks are objects that will never be used in the system and by any means are still be referenced directly or indirectly by once objects.

The objective of fixing a leak is find and cut one or more useless links to those once objects so that all the cycles/routes referenced can be garbage collected.

One thing one should keep in mind is that memory leaks we are talking about are not due to the language or compiler defeats, but the programmer makes them by programming illogically and incorrectly.

Examples

As demonstrated in the diagram, simple object relations in the memory is presented. Now Window manager is referring two windows. If they are all valid windows, we say there is NO memory leak here. But had one, say window_1, been destroyed, the whole branch of window_1 were memory leak. The bad link from Window manager to Window_1 illogically remains and prevents garbage collecting.

Fixing leaks by OC operation

Identifying memory leaks existence

1. Start debugging Eiffel Studio project, open a small project within the debugged Eiffel Studio.
2. Ctrl + Left click on Project setting toolbar button. You will see the GC Statistics window. Click "Men map", all objects in current system are listed with information of Object Type, Count and Delta. Object Type is just as the name implies. Count means the total number of that object type in current system. Delta means the variation of number between two "Men map" operations. Click Mem map again and again until you don't see Delta value any more. Note that clicking on the header of Delta sorts.
3. Carefully switch to the debugger Eiffel Studio window and open a new window, Ctrl + N is recommended, in case any mouse moving causes unwanted object variation. Close the new window.
4. Carefully switch back to the GC statistics window. Click on "Mem map" ONCE. Now you see under Delta the variations of all object. Ideally there should not be any delta value. If so you can hooray, otherwise, the real job of fixing memory leak just starts.

Identifying leaks in code

Choosing a starting object

Normally a closed EB_DEVELOPMENT_WINDOW is still connected, which means that the object cycles (it could be any kind of routes) involving this window are somehow connected to one or more once objects. The reason we choose start from EB_DEVELOPMENT_WINDOW is that it is a core class representing an Eiffel Studio window and it relates almost all modules of interfaces such as menus, toolbars and various tools.

Identifying the closed EB_DEVELOPMENT_WINDOW

Expand the node of EB_DEVELOPMENT_WINDOW, you will see two nodes. You might guess there must be one that was already closed. Yes, we are going to find the closed one. EB_DEVELOPMENT_WINDOW is derived from EB_RECYCLABLE. This class is used to help us with the job. When the window is closed, {EB_DEVELOPMENT_WINDOW}.recycle is called. Within the implementation we call `recycle' on almost all commands/tools so that references from those commands/tools are disconnected. By doing this, it is easy for us to find the closed window. Expand each of EB_DEVELOPMENT_WINDOW nodes, one with fewer client objects is the closed window. Same other leak objects like tools/commands can be found in the same way.