PR# 10935 Creating new window and closing it increases estudio and X server memory usage
Problem Report Summary
Submitter: prestoat2000
Category: EiffelStudio
Priority: Medium
Date: 2006/08/10
Class: Bug
Severity: Serious
Number: 10935
Release: 5.7.62110
Confidential: No
Status: Analyzed
Responsible: misterieking
Environment: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.10) Gecko/20050726 Firefox/1.0.6
Solaris 9 on SPARC
Synopsis: Creating new window and closing it increases estudio and X server memory usage
Description
Click on Create New Window button in estudio, then immediately close the new window. After about 40 repetitions of this sequence, size of ec goes from 100 MB to 200 MB (doubles) and size of Xsun (Sun's X server process) goes from 240 MB to 550 MB (more than doubles). Either there is a serious memory leak or you're accidentally or intentionally holding onto the closed windows. Whatever the explanation, it is very bad from a user's point of view.
To Reproduce
Problem Report Interactions
Yes, the problem still seems to be there. I tried using the GTK+2.10 since I think that version has fewer leaks of its own than GTK+2.4. Here are the results. Iterations refers to the number of open window then close window operations. Iterations Heap in MB 0 97 10 111 20 127 30 136 40 149 50 153 60 162 70 166 80 166 90 171 100 175 Memory growth seemed to slow down after awhile (last 40 iterations increased heap size by 13 MB, or about 300 KB per window open/close operation). Using memory analyzer seems to show an increase of around 200 of the following types of objects for a window open/close sequence: TUPLE [EV_FONT_IMP] EV_FONT_IMP PROCEDURE [EV_FONT_IMP, TUPLE [STRING_32]] EV_FONT EV_ACTIVE_LIST [STRING_32] SPECIAL [STRING_32] The deltas for these always .... Output truncated, Click download to get the full message
Do we still have the problem?
In build 62488, there is much less leaking but it is still present. Build 62110 leaked about 2.5 MB per window created and closed. Build 62488 leaks about 130 - 200 KB per main development window created and closed. So it is an order of magnitude better but still not completely fixed. I suggest use of Solaris Modular Debugger (mdb) as documented in another report to find where the memory that is still held at exit was allocated from. Or maybe you have other tools you can use on other platforms. I'm pretty sure part of this is related to GTK and might even be due to underlying GTK bugs (they seem to have a lot of memory leaks in that code), which might not be easy to work around.
There was indeed a memory leak in version 62110. Can you check the next release as there are no more Eiffel leaks now?