Digging memory leaks of EiffelStudio - Revision history

Peter gummer: /* Identifying memory leak existence */

2007-05-30T23:29:09Z

‎Identifying memory leak existence

Manus: Fixed link

2007-05-30T19:18:54Z

Fixed link

Ted: /* Find out Back to Once Routes */

2007-04-12T12:21:13Z

‎Find out Back to Once Routes

Ted: /* Typical Back to Once Routes */

2007-04-12T12:20:08Z

‎Typical Back to Once Routes

Ted: /* Identifying leaks in code */

2007-04-12T12:19:14Z

‎Identifying leaks in code

Ted: /* Typical Back to Once Routes */

2007-04-12T06:33:46Z

‎Typical Back to Once Routes

Ted: /* Typical Back to Once Routes */

2007-04-12T06:28:22Z

‎Typical Back to Once Routes

Ted: /* Typical Back to Once Routes */

2007-04-12T06:23:01Z

‎Typical Back to Once Routes

Ted: /* Definition */

2007-04-11T01:54:26Z

‎Definition

Ted: /* Identifying leaks in code */

2007-04-10T08:17:31Z

‎Identifying leaks in code

@@ Line 20: / Line 20: @@
 ==Identifying memory leak existence==
 # Start debugging Eiffel Studio project, open a small project within the debugged Eiffel Studio.
-# 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.
+# Ctrl + Left click on Project setting toolbar button. You will see the GC Statistics window. Click "Mem 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 "Mem 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.
 # 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.
 # 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.

@@ Line 35: / Line 35: @@
 ===Find out Back to Once Routes===
-Here we use the hidden tool in EiffelStudio activated by Ctrl + D, Memory Analyzer, to find out Back to Once routes which help pick leaks out. For the approach itself see [[Back to Once approach]].
+Here we use the hidden tool in EiffelStudio activated by Ctrl + D, Memory Analyzer, to find out Back to Once routes which help pick leaks out. For the approach itself see [[Back_to_once_approach| Back to once approach]].
 ===Typical Back to Once Routes===

@@ Line 35: / Line 35: @@
 ===Find out Back to Once Routes===
-Here we use the hidden tool in EiffelStudio activated by Ctrl + D, Memory Analyzer, to find out Back to Once routes which help pick leaks out.
+Here we use the hidden tool in EiffelStudio activated by Ctrl + D, Memory Analyzer, to find out Back to Once routes which help pick leaks out. For the approach itself see [[Back to Once approach]].
 ===Typical Back to Once Routes===

← Older revision		Revision as of 12:20, 12 April 2007
Line 38:		Line 38:

	===Typical Back to Once Routes===		===Typical Back to Once Routes===
−	~~Now we can utilize [[Back to Once approach]] to find leaks in EiffelStudio.~~
	There are several typical ways causing memory leak in EiffelStudio.		There are several typical ways causing memory leak in EiffelStudio.

@@ Line 33: / Line 33: @@
 ===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. Some other leak objects like tools/commands can be found in the same way.
 ===Typical Back to Once Routes===
@@ Line 58: / Line 61: @@
 * <b>TEXT_PANEL and this descendants not recycled</b>
 Not doing this, once instance of TEXT_PANEL_MANAGER would not remove the TEXT_PANEL from management.

@@ Line 50: / Line 50: @@
 Take EB_DEBUGGER_MANAGER as an example. `debugging_window: EB_DEVELOPMENT_WINDOW' refers to the window that debugging tools are raised or to be raised. When a window is closed, we need to check if this window is the `debugging_window' and refresh this field, otherwise, the closed window will be referred. And not only do memory leaks occur, but also would it cause crash when one trying to operate on the non-existing window.
-* <b>Instances of EB_PREFERENCED_TOOL_BAR_TOGGLE_BUTTON are not recycled</b>
+* <b>EB_PREFERENCED_TOOL_BAR_TOGGLE_BUTTON not recycled</b>
 `synchronizer' need to `deregister_host' when the button is useless. Normally `deregister_host' removes agents from preferences. Not doing this would cause leaks of <b>Preference related</b>.
-* <b>EB_EDITOR_TOKEN_GRID_SUPPORT</b>
+* <b>EB_EDITOR_TOKEN_GRID_SUPPORT not desynchronized</b>
 `desynchronize*' MUST be called at disposal when `synchronize*' was once called. Not doing this would cause leaks of <b>Preference related</b>.

@@ Line 37: / Line 37: @@
 Now we can utilize [[Back to Once approach]] to find leaks in EiffelStudio.
 There are several typical ways causing memory leak in EiffelStudio.
-====Preference related====
 Preferences are initialized and referred by once object (CELL). As we use many of {PREFERENCE}.change_actions to reflect a changes of any type of preference. This could  easily cause memory leaks. For example, when initializing a tool in a new opened window, we extend `agent {TOOL}.routine', into {PREFERENCE}.change_actions. This operation internally create a TUPLE [TOOL] referred by a PROCEDURE [TOOL, TUPLE] referred by a SPECIAL [PROCEDURE [ANY, TUPLE [ANY]]] of {PREFERENCE}.change_actions. When closing a window, if one do not remove this agent from {PREFERENCE}.change_actions, a leak occurs. Consequently, the object of a closed development window normally referred by the tool is not collected. Of course, other tools referred by this window will nor be collected.
-====Application related====
+Application related
 An object of EV_APPLICATION is referred by once object. The same as previous case, there are incorrectly extending *actions without removing will cause memory leaks.
-====Menuable or toolbarable commands====
+* <b>Menuable or toolbarable commands</b>
 Once objects of menuable or toolbarable commands can easily cause memory leaks. See EB_MENUABLE_COMMAND and EB_TOOLBARABLE_COMMAND, when we do new_*_item, we get a new item for the interface. But one should notice that in creation routine of those interface classes, i.e. EB_COMMAND_TOOL_BAR_BUTTON, EB_SD_COMMAND_TOOL_BAR_BUTTON and EB_COMMAND_MENU_ITEM, the item itself is inserted into the command object. This means that if one do not call `recycle' on interface items when they are not used anymore, leaks occurs in the once command objects.
-====Once managers focusing on one window====
+* <b>Once managers focusing on one window</b>
 Take EB_DEBUGGER_MANAGER as an example. `debugging_window: EB_DEVELOPMENT_WINDOW' refers to the window that debugging tools are raised or to be raised. When a window is closed, we need to check if this window is the `debugging_window' and refresh this field, otherwise, the closed window will be referred. And not only do memory leaks occur, but also would it cause crash when one trying to operate on the non-existing window.
-====Instances of EB_PREFERENCED_TOOL_BAR_TOGGLE_BUTTON are not recycled====
+* <b>Instances of EB_PREFERENCED_TOOL_BAR_TOGGLE_BUTTON are not recycled</b>
-`synchronizer' need to `deregister_host' when the button is useless. Normally `deregister_host' removes agents from preferences.
+`synchronizer' need to `deregister_host' when the button is useless. Normally `deregister_host' removes agents from preferences. Not doing this would cause leaks of <b>Preference related</b>.
-====EB_EDITOR_TOKEN_GRID_SUPPORT====
+* <b>EB_EDITOR_TOKEN_GRID_SUPPORT</b>
-`desynchronize*' MUST be called at disposal when `synchronize*' was once called.
+`desynchronize*' MUST be called at disposal when `synchronize*' was once called. Not doing this would cause leaks of <b>Preference related</b>.

← Older revision		Revision as of 06:23, 12 April 2007
Line 48:		Line 48:
	====Once managers focusing on one window====		====Once managers focusing on one window====
	Take EB_DEBUGGER_MANAGER as an example. `debugging_window: EB_DEVELOPMENT_WINDOW' refers to the window that debugging tools are raised or to be raised. When a window is closed, we need to check if this window is the `debugging_window' and refresh this field, otherwise, the closed window will be referred. And not only do memory leaks occur, but also would it cause crash when one trying to operate on the non-existing window.		Take EB_DEBUGGER_MANAGER as an example. `debugging_window: EB_DEVELOPMENT_WINDOW' refers to the window that debugging tools are raised or to be raised. When a window is closed, we need to check if this window is the `debugging_window' and refresh this field, otherwise, the closed window will be referred. And not only do memory leaks occur, but also would it cause crash when one trying to operate on the non-existing window.
		+
		+	====Instances of EB_PREFERENCED_TOOL_BAR_TOGGLE_BUTTON are not recycled====
		+	`synchronizer' need to `deregister_host' when the button is useless. Normally `deregister_host' removes agents from preferences.
		+
		+	====EB_EDITOR_TOKEN_GRID_SUPPORT====
		+	`desynchronize' MUST be called at disposal when `synchronize' was once called.

@@ Line 5: / Line 5: @@
 =What is memory leak=
 ==Definition==
-<b>{{red| 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.}}</b>
+<b>{{red| Memory leaks are objects that will never be used in the system and by any means are still be referred directly or indirectly by once objects.}}</b>
 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.
@@ Line 11: / Line 11: @@
 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.
 ==Example==
 [[Image:Leak_example.PNG]]

← Older revision		Revision as of 08:17, 10 April 2007
Line 44:		Line 44:
	====Menuable or toolbarable commands====		====Menuable or toolbarable commands====
	Once objects of menuable or toolbarable commands can easily cause memory leaks. See EB_MENUABLE_COMMAND and EB_TOOLBARABLE_COMMAND, when we do new_*_item, we get a new item for the interface. But one should notice that in creation routine of those interface classes, i.e. EB_COMMAND_TOOL_BAR_BUTTON, EB_SD_COMMAND_TOOL_BAR_BUTTON and EB_COMMAND_MENU_ITEM, the item itself is inserted into the command object. This means that if one do not call `recycle' on interface items when they are not used anymore, leaks occurs in the once command objects.		Once objects of menuable or toolbarable commands can easily cause memory leaks. See EB_MENUABLE_COMMAND and EB_TOOLBARABLE_COMMAND, when we do new_*_item, we get a new item for the interface. But one should notice that in creation routine of those interface classes, i.e. EB_COMMAND_TOOL_BAR_BUTTON, EB_SD_COMMAND_TOOL_BAR_BUTTON and EB_COMMAND_MENU_ITEM, the item itself is inserted into the command object. This means that if one do not call `recycle' on interface items when they are not used anymore, leaks occurs in the once command objects.
		+
		+	====Once managers focusing on one window====
		+	Take EB_DEBUGGER_MANAGER as an example. `debugging_window: EB_DEVELOPMENT_WINDOW' refers to the window that debugging tools are raised or to be raised. When a window is closed, we need to check if this window is the `debugging_window' and refresh this field, otherwise, the closed window will be referred. And not only do memory leaks occur, but also would it cause crash when one trying to operate on the non-existing window.