TextInput内存泄露缺陷 Flex TextInput Memory Leak Bug

During development of my UI module system, I encountered one of  Flex SDK's bugs - memory leak when using TextInput and TextArea when click the keyboard. It turns out it is not big deal but it did waste hours of my time.

Here is how you can replicate the bug - you use ActionScript to create two text inputs and add them to the screen:

...
addChild(new TextInput());
addChild(new TextInput());

Type a letter in the first TextInput, then execute the following code (maybe through a button's click event handler function):

removeChildAt(0); // the first TextInput

Now, the first TextInput should be eligible for garbage collection. However, when you execute garbage collection, it will not be removed. One work around is that you input some text in the TextInput left on the screen and execute garbage collection again, this time the previously removed TextInput will be garbage collected.

This is an annoying bug. Most of the time, when a TextInput is not garbage collected, there are quite a number of related objects will not be garbage collected either.

I have not figure out a decent solution yet. Anyway, for now I just leave it as is and wait for the fix in Flex SDK milestone 3.2.0.

P.S. How a TextInput holds a large object network

The TextInput is managed by AttributeEditorUI. In order to listen for user input, AttributeEditorUI adds listener function to the TextInput. Thus AttributeEditorUI and the TextInput is now connected in both directions. AttributeEditorUI holds a reference to the editorUIGroup and the editorUIGroup holds references to all AttributeEditorUI it manages. editorUIGroup is now connected with AttributeEditorUI. Similarly, the editorUIGroup is connected to the entity editor (since the editor listens for change events in the editorUIGroup). So listeners are the root of all evil.

However, one strange aspect I noticed that even the module points to the entity editor in one direction (i.e., the module refers to the entity editor but not the other way around), the module will be not garbage collected. Theoretically, it should be. It could be due to the implementation of the flash VM. I am not able to determine the final cause due to the lack of documentation on the VM.