You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@flex.apache.org by After24 <vi...@after24.net> on 2013/10/31 12:20:46 UTC
Memory leaks management in modules
Hello list,
I'm working on a modular application where all services and value objects
are stored in a RSL. The inconvenient with this organization is that when a
value object alias is registered by a module during an AMF call it cause a
memory leak revealed by a console warning :
warning: The class myValueObject has been used in a call to
net.registerClassAlias() in _myModule_FlexInit. This will cause myModule to
be leaked. To resolve the leak, define myValueObject in the top-level
application.
I want my value objects to be in a RSL so my workaround is to force the main
application to register the alias of all VO's at startup in a loop :
public function RegisterClasses()
{
var classDefinitions:Vector.<String> =
ApplicationDomain.currentDomain.getQualifiedDefinitionNames();
for (var i:int = 0; i < classDefinitions.length; i++)
{
if (classDefinitions[i].indexOf("fr.mydomain.core.vo") >= 0)
{
var aliasName:String =
String(classDefinitions[i].split(".").pop()).replace("::", ".");
registerClassAlias(aliasName, getDefinitionByName(classDefinitions[i])
as Class);
}
}
}
It works but if anyone found a better way to handle this issue I would be
glad to hear how.
Thanks.
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management-in-modules-tp3422.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Memory leaks management in modules
Posted by Alex Harui <ah...@adobe.com>.
Well, TLF might be keeping something around until that last keystroke. If
you duplicate the situation with just FTE (more or less) that should tell
you if it is the player or other code.
On 11/7/13 1:53 PM, "After24" <vi...@after24.net> wrote:
>I think the hypothesis of a memory leak coming from the text layout
>framework is not valid.
>I thought that it was the fact of entering text in a text input of the
>main app that allowed the GC to collect the module but in fact, after
>unloading the module, you just have to type something on the keyboard
>and the module memory can be released.
>
>If the module contains a button, the fact of clicking on this button and
>then typing something on the keyboard prevents the module from being
>garbage collected.
>
>
>Le 05/11/13 23:26, Alex Harui a écrit :
>> OK. I think the next test would be to examine the loitering objects in
>> the profiler. I think you said you determined the action that causes the
>> leak is to type something? If so, then take a memory snapshot before and
>> after typing and look to see what is loitering objects and see if they
>>are
>> being held in by static variables in TLF.
>>
>> -Alex
>>
>> On 11/5/13 2:18 PM, "After24" <vi...@after24.net> wrote:
>>
>>> I have updated the testCase by adding a flash text engine based text
>>> field.
>>> When this text field is clicked, the text of the TextElement is
>>>replaced
>>> and the TextLine is updated using the TextBlock.recreateTextLine()
>>>method.
>>>
>>> After this process the module is still garbage collected.
>>>
>>> https://issues.apache.org/jira/browse/FLEX-338
>>>
>>>
>>>
>>> Le 05/11/13 18:51, Alex Harui a écrit :
>>>> I don't think you need to build a whole TextInput. Fundamentally, TLF
>>>> just generates TextLines from TextBlocks and recycles them if it can.
>>>> I
>>>> think the FTE test just has to do some of that.
>>>>
>>>> -Alex
>>>>
>>>> On 11/5/13 3:59 AM, "After24" <vi...@after24.net> wrote:
>>>>
>>>>> Hello Alex,
>>>>>
>>>>> Creating a TextInput component based on FTE is not an easy task given
>>>>> the low level nature of this engine.
>>>>> Maybe a framework like TinyTLF which has no dependancies with TLF can
>>>>> be
>>>>> used to check that the memory leak comes from TLF or FLEX ?
>>>>>
>>>>>
>>>>>
>>>>> Le 04/11/13 22:38, Alex Harui a écrit :
>>>>>> If you have time to investigate, the next test is to use
>>>>>> flash.text.engine
>>>>>> classes in an AS-only project. My guess, though, is that there are
>>>>>> static
>>>>>> variables in Flex and TLF that may be holding onto something.
>>>>>>
>>>>>> On 11/4/13 1:10 PM, "After24" <vi...@after24.net> wrote:
>>>>>>
>>>>>>> Until now, my investigations leads me nowhere. My hypothesis is
>>>>>>>that
>>>>>>> an
>>>>>>> object (of the TLF framework) keeps a reference to the textflow of
>>>>>>> the
>>>>>>> text
>>>>>>> input control but I'm really not sure. If someone has an idea of
>>>>>>> where
>>>>>>> to
>>>>>>> search I'm interested.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-manageme
>>>>>>>nt
>>>>>>> -i
>>>>>>> n-
>>>>>>> modules-tp3422p3528.html
>>>>>>> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>>
>
Re: Memory leaks management in modules
Posted by After24 <vi...@after24.net>.
I think the hypothesis of a memory leak coming from the text layout
framework is not valid.
I thought that it was the fact of entering text in a text input of the
main app that allowed the GC to collect the module but in fact, after
unloading the module, you just have to type something on the keyboard
and the module memory can be released.
If the module contains a button, the fact of clicking on this button and
then typing something on the keyboard prevents the module from being
garbage collected.
Le 05/11/13 23:26, Alex Harui a écrit :
> OK. I think the next test would be to examine the loitering objects in
> the profiler. I think you said you determined the action that causes the
> leak is to type something? If so, then take a memory snapshot before and
> after typing and look to see what is loitering objects and see if they are
> being held in by static variables in TLF.
>
> -Alex
>
> On 11/5/13 2:18 PM, "After24" <vi...@after24.net> wrote:
>
>> I have updated the testCase by adding a flash text engine based text
>> field.
>> When this text field is clicked, the text of the TextElement is replaced
>> and the TextLine is updated using the TextBlock.recreateTextLine() method.
>>
>> After this process the module is still garbage collected.
>>
>> https://issues.apache.org/jira/browse/FLEX-338
>>
>>
>>
>> Le 05/11/13 18:51, Alex Harui a écrit :
>>> I don't think you need to build a whole TextInput. Fundamentally, TLF
>>> just generates TextLines from TextBlocks and recycles them if it can. I
>>> think the FTE test just has to do some of that.
>>>
>>> -Alex
>>>
>>> On 11/5/13 3:59 AM, "After24" <vi...@after24.net> wrote:
>>>
>>>> Hello Alex,
>>>>
>>>> Creating a TextInput component based on FTE is not an easy task given
>>>> the low level nature of this engine.
>>>> Maybe a framework like TinyTLF which has no dependancies with TLF can
>>>> be
>>>> used to check that the memory leak comes from TLF or FLEX ?
>>>>
>>>>
>>>>
>>>> Le 04/11/13 22:38, Alex Harui a écrit :
>>>>> If you have time to investigate, the next test is to use
>>>>> flash.text.engine
>>>>> classes in an AS-only project. My guess, though, is that there are
>>>>> static
>>>>> variables in Flex and TLF that may be holding onto something.
>>>>>
>>>>> On 11/4/13 1:10 PM, "After24" <vi...@after24.net> wrote:
>>>>>
>>>>>> Until now, my investigations leads me nowhere. My hypothesis is that
>>>>>> an
>>>>>> object (of the TLF framework) keeps a reference to the textflow of
>>>>>> the
>>>>>> text
>>>>>> input control but I'm really not sure. If someone has an idea of
>>>>>> where
>>>>>> to
>>>>>> search I'm interested.
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>>
>>>>>>
>>>>>> http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management
>>>>>> -i
>>>>>> n-
>>>>>> modules-tp3422p3528.html
>>>>>> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>
Re: Memory leaks management in modules
Posted by Alex Harui <ah...@adobe.com>.
OK. I think the next test would be to examine the loitering objects in
the profiler. I think you said you determined the action that causes the
leak is to type something? If so, then take a memory snapshot before and
after typing and look to see what is loitering objects and see if they are
being held in by static variables in TLF.
-Alex
On 11/5/13 2:18 PM, "After24" <vi...@after24.net> wrote:
>I have updated the testCase by adding a flash text engine based text
>field.
>When this text field is clicked, the text of the TextElement is replaced
>and the TextLine is updated using the TextBlock.recreateTextLine() method.
>
>After this process the module is still garbage collected.
>
>https://issues.apache.org/jira/browse/FLEX-338
>
>
>
>Le 05/11/13 18:51, Alex Harui a écrit :
>> I don't think you need to build a whole TextInput. Fundamentally, TLF
>> just generates TextLines from TextBlocks and recycles them if it can. I
>> think the FTE test just has to do some of that.
>>
>> -Alex
>>
>> On 11/5/13 3:59 AM, "After24" <vi...@after24.net> wrote:
>>
>>> Hello Alex,
>>>
>>> Creating a TextInput component based on FTE is not an easy task given
>>> the low level nature of this engine.
>>> Maybe a framework like TinyTLF which has no dependancies with TLF can
>>>be
>>> used to check that the memory leak comes from TLF or FLEX ?
>>>
>>>
>>>
>>> Le 04/11/13 22:38, Alex Harui a écrit :
>>>> If you have time to investigate, the next test is to use
>>>> flash.text.engine
>>>> classes in an AS-only project. My guess, though, is that there are
>>>> static
>>>> variables in Flex and TLF that may be holding onto something.
>>>>
>>>> On 11/4/13 1:10 PM, "After24" <vi...@after24.net> wrote:
>>>>
>>>>> Until now, my investigations leads me nowhere. My hypothesis is that
>>>>>an
>>>>> object (of the TLF framework) keeps a reference to the textflow of
>>>>>the
>>>>> text
>>>>> input control but I'm really not sure. If someone has an idea of
>>>>>where
>>>>> to
>>>>> search I'm interested.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>>
>>>>>
>>>>>http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management
>>>>>-i
>>>>> n-
>>>>> modules-tp3422p3528.html
>>>>> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>>
>
Re: Memory leaks management in modules
Posted by After24 <vi...@after24.net>.
I have updated the testCase by adding a flash text engine based text field.
When this text field is clicked, the text of the TextElement is replaced
and the TextLine is updated using the TextBlock.recreateTextLine() method.
After this process the module is still garbage collected.
https://issues.apache.org/jira/browse/FLEX-338
Le 05/11/13 18:51, Alex Harui a écrit :
> I don't think you need to build a whole TextInput. Fundamentally, TLF
> just generates TextLines from TextBlocks and recycles them if it can. I
> think the FTE test just has to do some of that.
>
> -Alex
>
> On 11/5/13 3:59 AM, "After24" <vi...@after24.net> wrote:
>
>> Hello Alex,
>>
>> Creating a TextInput component based on FTE is not an easy task given
>> the low level nature of this engine.
>> Maybe a framework like TinyTLF which has no dependancies with TLF can be
>> used to check that the memory leak comes from TLF or FLEX ?
>>
>>
>>
>> Le 04/11/13 22:38, Alex Harui a écrit :
>>> If you have time to investigate, the next test is to use
>>> flash.text.engine
>>> classes in an AS-only project. My guess, though, is that there are
>>> static
>>> variables in Flex and TLF that may be holding onto something.
>>>
>>> On 11/4/13 1:10 PM, "After24" <vi...@after24.net> wrote:
>>>
>>>> Until now, my investigations leads me nowhere. My hypothesis is that an
>>>> object (of the TLF framework) keeps a reference to the textflow of the
>>>> text
>>>> input control but I'm really not sure. If someone has an idea of where
>>>> to
>>>> search I'm interested.
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>>
>>>> http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management-i
>>>> n-
>>>> modules-tp3422p3528.html
>>>> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>
Re: Memory leaks management in modules
Posted by After24 <vi...@after24.net>.
Ok, understood. I will set up a test.
Le 05/11/13 18:51, Alex Harui a écrit :
> I don't think you need to build a whole TextInput. Fundamentally, TLF
> just generates TextLines from TextBlocks and recycles them if it can. I
> think the FTE test just has to do some of that.
>
> -Alex
>
> On 11/5/13 3:59 AM, "After24" <vi...@after24.net> wrote:
>
>> Hello Alex,
>>
>> Creating a TextInput component based on FTE is not an easy task given
>> the low level nature of this engine.
>> Maybe a framework like TinyTLF which has no dependancies with TLF can be
>> used to check that the memory leak comes from TLF or FLEX ?
>>
>>
>>
>> Le 04/11/13 22:38, Alex Harui a écrit :
>>> If you have time to investigate, the next test is to use
>>> flash.text.engine
>>> classes in an AS-only project. My guess, though, is that there are
>>> static
>>> variables in Flex and TLF that may be holding onto something.
>>>
>>> On 11/4/13 1:10 PM, "After24" <vi...@after24.net> wrote:
>>>
>>>> Until now, my investigations leads me nowhere. My hypothesis is that an
>>>> object (of the TLF framework) keeps a reference to the textflow of the
>>>> text
>>>> input control but I'm really not sure. If someone has an idea of where
>>>> to
>>>> search I'm interested.
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>>
>>>> http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management-i
>>>> n-
>>>> modules-tp3422p3528.html
>>>> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>
Re: Memory leaks management in modules
Posted by Alex Harui <ah...@adobe.com>.
I don't think you need to build a whole TextInput. Fundamentally, TLF
just generates TextLines from TextBlocks and recycles them if it can. I
think the FTE test just has to do some of that.
-Alex
On 11/5/13 3:59 AM, "After24" <vi...@after24.net> wrote:
>Hello Alex,
>
>Creating a TextInput component based on FTE is not an easy task given
>the low level nature of this engine.
>Maybe a framework like TinyTLF which has no dependancies with TLF can be
>used to check that the memory leak comes from TLF or FLEX ?
>
>
>
>Le 04/11/13 22:38, Alex Harui a écrit :
>> If you have time to investigate, the next test is to use
>>flash.text.engine
>> classes in an AS-only project. My guess, though, is that there are
>>static
>> variables in Flex and TLF that may be holding onto something.
>>
>> On 11/4/13 1:10 PM, "After24" <vi...@after24.net> wrote:
>>
>>> Until now, my investigations leads me nowhere. My hypothesis is that an
>>> object (of the TLF framework) keeps a reference to the textflow of the
>>> text
>>> input control but I'm really not sure. If someone has an idea of where
>>>to
>>> search I'm interested.
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>>
>>>http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management-i
>>>n-
>>> modules-tp3422p3528.html
>>> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>>
>
Re: Memory leaks management in modules
Posted by After24 <vi...@after24.net>.
Hello Alex,
Creating a TextInput component based on FTE is not an easy task given
the low level nature of this engine.
Maybe a framework like TinyTLF which has no dependancies with TLF can be
used to check that the memory leak comes from TLF or FLEX ?
Le 04/11/13 22:38, Alex Harui a écrit :
> If you have time to investigate, the next test is to use flash.text.engine
> classes in an AS-only project. My guess, though, is that there are static
> variables in Flex and TLF that may be holding onto something.
>
> On 11/4/13 1:10 PM, "After24" <vi...@after24.net> wrote:
>
>> Until now, my investigations leads me nowhere. My hypothesis is that an
>> object (of the TLF framework) keeps a reference to the textflow of the
>> text
>> input control but I'm really not sure. If someone has an idea of where to
>> search I'm interested.
>>
>>
>>
>> --
>> View this message in context:
>> http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management-in-
>> modules-tp3422p3528.html
>> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>
Re: Memory leaks management in modules
Posted by Alex Harui <ah...@adobe.com>.
If you have time to investigate, the next test is to use flash.text.engine
classes in an AS-only project. My guess, though, is that there are static
variables in Flex and TLF that may be holding onto something.
On 11/4/13 1:10 PM, "After24" <vi...@after24.net> wrote:
>Until now, my investigations leads me nowhere. My hypothesis is that an
>object (of the TLF framework) keeps a reference to the textflow of the
>text
>input control but I'm really not sure. If someone has an idea of where to
>search I'm interested.
>
>
>
>--
>View this message in context:
>http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management-in-
>modules-tp3422p3528.html
>Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Memory leaks management in modules
Posted by After24 <vi...@after24.net>.
Until now, my investigations leads me nowhere. My hypothesis is that an
object (of the TLF framework) keeps a reference to the textflow of the text
input control but I'm really not sure. If someone has an idea of where to
search I'm interested.
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management-in-modules-tp3422p3528.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Memory leaks management in modules
Posted by After24 <vi...@after24.net>.
Done.
https://issues.apache.org/jira/browse/FLEX-33873
Le 03/11/13 04:06, Alex Harui a écrit :
> OK, file a bug with a simple test case.
>
> -Alex
>
> On 11/2/13 9:57 AM, "After24" <vi...@after24.net> wrote:
>
>> Alex,
>>
>> The module can be garbage collected when a flash.text.TextField is used
>> instead of a Spark TextInput.
>> Like you said, the problem seems to come from the text layout framework.
>>
>>
>> Le 02/11/13 16:58, Alex Harui a écrit :
>>> Switch to mx:TextInputs and/or TextField and see if the problem
>>> persists.
>>> It could be that TLF sets up the flash.text.engine classes in a way that
>>> references are kept to TextLines and/or their containers.
>>>
>>> -Alex
>>>
>>> On 11/2/13 8:53 AM, "After24" <vi...@after24.net> wrote:
>>>
>>>> The main app contains the TextInput to wich I give focus before
>>>> unloading the module. I replaced it with a button but it changes
>>>> nothing.
>>>>
>>>> I tried the pure actionScript version with a textflow. I added to the
>>>> flowComposer a ContainerController based on a sprite. Unfortunatly, the
>>>> module is not garbage collected.
>>>>
>>>> Le 02/11/13 16:20, Alex Harui a écrit :
>>>>> Are there Spark Text controls in the main app? If so, there could be
>>>>> some
>>>>> static vars in TLF that hang onto the control in the module.
>>>>>
>>>>> On 11/2/13 8:05 AM, "After24" <vi...@after24.net> wrote:
>>>>>
>>>>>> Hi Alex,
>>>>>>
>>>>>> Thank you very much.
>>>>>> It's a spark TextInput.
>>>>>>
>>>>>> I will continue to investigate.
>>>>>>
>>>>>>
>>>>>> Le 02/11/13 15:35, Alex Harui a écrit :
>>>>>>> Is this mx TextInput or Spark? Spark might be managing some undo
>>>>>>> stack
>>>>>>> or
>>>>>>> something like that.
>>>>>>>
>>>>>>> A good test is to build an AS-only equivalent and see if there is
>>>>>>> still
>>>>>>> a
>>>>>>> problem.
>>>>>>>
>>>>>>> -Alex
>>>>>>>
>>>>>>> On 11/2/13 4:11 AM, "After24" <vi...@after24.net> wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I found out that the memory leak is caused by the focus manager.
>>>>>>>>
>>>>>>>> So concerning the warning about the module calling
>>>>>>>> net.registerClassAlias()
>>>>>>>> -> the module is garbage collected even when those warnings pops up
>>>>>>>> in
>>>>>>>> the
>>>>>>>> console.
>>>>>>>>
>>>>>>>> Now I'm stuck with the focus manager causing a memory leak :
>>>>>>>>
>>>>>>>> After reading some blog posts about the correct way to handle
>>>>>>>> module
>>>>>>>> unloading (From Alex Harui ,Tom Sugden) I added a textInput in the
>>>>>>>> shell
>>>>>>>> application to which I give focus just before module unloading :
>>>>>>>> Now if a module button is clicked or if the focus is given to a
>>>>>>>> textinput
>>>>>>>> without typing anything, the module instance disappears when the
>>>>>>>> run
>>>>>>>> Garbage
>>>>>>>> collector button is pressed but if some text is typed in a
>>>>>>>> textInput
>>>>>>>> the
>>>>>>>> module stays in memory.
>>>>>>>> I used the debugger to see if the focusManager instance keeps a
>>>>>>>> reference
>>>>>>>> to
>>>>>>>> a module control but I don't found anything.
>>>>>>>>
>>>>>>>> Any idea ?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> View this message in context:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-manageme
>>>>>>>> nt
>>>>>>>> -i
>>>>>>>> n-
>>>>>>>> modules-tp3422p3482.html
>>>>>>>> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>
Re: Memory leaks management in modules
Posted by Alex Harui <ah...@adobe.com>.
OK, file a bug with a simple test case.
-Alex
On 11/2/13 9:57 AM, "After24" <vi...@after24.net> wrote:
>Alex,
>
>The module can be garbage collected when a flash.text.TextField is used
>instead of a Spark TextInput.
>Like you said, the problem seems to come from the text layout framework.
>
>
>Le 02/11/13 16:58, Alex Harui a écrit :
>> Switch to mx:TextInputs and/or TextField and see if the problem
>>persists.
>> It could be that TLF sets up the flash.text.engine classes in a way that
>> references are kept to TextLines and/or their containers.
>>
>> -Alex
>>
>> On 11/2/13 8:53 AM, "After24" <vi...@after24.net> wrote:
>>
>>> The main app contains the TextInput to wich I give focus before
>>> unloading the module. I replaced it with a button but it changes
>>>nothing.
>>>
>>> I tried the pure actionScript version with a textflow. I added to the
>>> flowComposer a ContainerController based on a sprite. Unfortunatly, the
>>> module is not garbage collected.
>>>
>>> Le 02/11/13 16:20, Alex Harui a écrit :
>>>> Are there Spark Text controls in the main app? If so, there could be
>>>> some
>>>> static vars in TLF that hang onto the control in the module.
>>>>
>>>> On 11/2/13 8:05 AM, "After24" <vi...@after24.net> wrote:
>>>>
>>>>> Hi Alex,
>>>>>
>>>>> Thank you very much.
>>>>> It's a spark TextInput.
>>>>>
>>>>> I will continue to investigate.
>>>>>
>>>>>
>>>>> Le 02/11/13 15:35, Alex Harui a écrit :
>>>>>> Is this mx TextInput or Spark? Spark might be managing some undo
>>>>>> stack
>>>>>> or
>>>>>> something like that.
>>>>>>
>>>>>> A good test is to build an AS-only equivalent and see if there is
>>>>>> still
>>>>>> a
>>>>>> problem.
>>>>>>
>>>>>> -Alex
>>>>>>
>>>>>> On 11/2/13 4:11 AM, "After24" <vi...@after24.net> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I found out that the memory leak is caused by the focus manager.
>>>>>>>
>>>>>>> So concerning the warning about the module calling
>>>>>>> net.registerClassAlias()
>>>>>>> -> the module is garbage collected even when those warnings pops up
>>>>>>> in
>>>>>>> the
>>>>>>> console.
>>>>>>>
>>>>>>> Now I'm stuck with the focus manager causing a memory leak :
>>>>>>>
>>>>>>> After reading some blog posts about the correct way to handle
>>>>>>>module
>>>>>>> unloading (From Alex Harui ,Tom Sugden) I added a textInput in the
>>>>>>> shell
>>>>>>> application to which I give focus just before module unloading :
>>>>>>> Now if a module button is clicked or if the focus is given to a
>>>>>>> textinput
>>>>>>> without typing anything, the module instance disappears when the
>>>>>>>run
>>>>>>> Garbage
>>>>>>> collector button is pressed but if some text is typed in a
>>>>>>>textInput
>>>>>>> the
>>>>>>> module stays in memory.
>>>>>>> I used the debugger to see if the focusManager instance keeps a
>>>>>>> reference
>>>>>>> to
>>>>>>> a module control but I don't found anything.
>>>>>>>
>>>>>>> Any idea ?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-manageme
>>>>>>>nt
>>>>>>> -i
>>>>>>> n-
>>>>>>> modules-tp3422p3482.html
>>>>>>> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>>
>
Re: Memory leaks management in modules
Posted by After24 <vi...@after24.net>.
Alex,
The module can be garbage collected when a flash.text.TextField is used
instead of a Spark TextInput.
Like you said, the problem seems to come from the text layout framework.
Le 02/11/13 16:58, Alex Harui a écrit :
> Switch to mx:TextInputs and/or TextField and see if the problem persists.
> It could be that TLF sets up the flash.text.engine classes in a way that
> references are kept to TextLines and/or their containers.
>
> -Alex
>
> On 11/2/13 8:53 AM, "After24" <vi...@after24.net> wrote:
>
>> The main app contains the TextInput to wich I give focus before
>> unloading the module. I replaced it with a button but it changes nothing.
>>
>> I tried the pure actionScript version with a textflow. I added to the
>> flowComposer a ContainerController based on a sprite. Unfortunatly, the
>> module is not garbage collected.
>>
>> Le 02/11/13 16:20, Alex Harui a écrit :
>>> Are there Spark Text controls in the main app? If so, there could be
>>> some
>>> static vars in TLF that hang onto the control in the module.
>>>
>>> On 11/2/13 8:05 AM, "After24" <vi...@after24.net> wrote:
>>>
>>>> Hi Alex,
>>>>
>>>> Thank you very much.
>>>> It's a spark TextInput.
>>>>
>>>> I will continue to investigate.
>>>>
>>>>
>>>> Le 02/11/13 15:35, Alex Harui a écrit :
>>>>> Is this mx TextInput or Spark? Spark might be managing some undo
>>>>> stack
>>>>> or
>>>>> something like that.
>>>>>
>>>>> A good test is to build an AS-only equivalent and see if there is
>>>>> still
>>>>> a
>>>>> problem.
>>>>>
>>>>> -Alex
>>>>>
>>>>> On 11/2/13 4:11 AM, "After24" <vi...@after24.net> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I found out that the memory leak is caused by the focus manager.
>>>>>>
>>>>>> So concerning the warning about the module calling
>>>>>> net.registerClassAlias()
>>>>>> -> the module is garbage collected even when those warnings pops up
>>>>>> in
>>>>>> the
>>>>>> console.
>>>>>>
>>>>>> Now I'm stuck with the focus manager causing a memory leak :
>>>>>>
>>>>>> After reading some blog posts about the correct way to handle module
>>>>>> unloading (From Alex Harui ,Tom Sugden) I added a textInput in the
>>>>>> shell
>>>>>> application to which I give focus just before module unloading :
>>>>>> Now if a module button is clicked or if the focus is given to a
>>>>>> textinput
>>>>>> without typing anything, the module instance disappears when the run
>>>>>> Garbage
>>>>>> collector button is pressed but if some text is typed in a textInput
>>>>>> the
>>>>>> module stays in memory.
>>>>>> I used the debugger to see if the focusManager instance keeps a
>>>>>> reference
>>>>>> to
>>>>>> a module control but I don't found anything.
>>>>>>
>>>>>> Any idea ?
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>>
>>>>>>
>>>>>> http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management
>>>>>> -i
>>>>>> n-
>>>>>> modules-tp3422p3482.html
>>>>>> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>
Re: Memory leaks management in modules
Posted by After24 <vi...@after24.net>.
Thank you Alex,
I will try .
Le 02/11/13 16:58, Alex Harui a écrit :
> Switch to mx:TextInputs and/or TextField and see if the problem persists.
> It could be that TLF sets up the flash.text.engine classes in a way that
> references are kept to TextLines and/or their containers.
>
> -Alex
>
> On 11/2/13 8:53 AM, "After24" <vi...@after24.net> wrote:
>
>> The main app contains the TextInput to wich I give focus before
>> unloading the module. I replaced it with a button but it changes nothing.
>>
>> I tried the pure actionScript version with a textflow. I added to the
>> flowComposer a ContainerController based on a sprite. Unfortunatly, the
>> module is not garbage collected.
>>
>> Le 02/11/13 16:20, Alex Harui a écrit :
>>> Are there Spark Text controls in the main app? If so, there could be
>>> some
>>> static vars in TLF that hang onto the control in the module.
>>>
>>> On 11/2/13 8:05 AM, "After24" <vi...@after24.net> wrote:
>>>
>>>> Hi Alex,
>>>>
>>>> Thank you very much.
>>>> It's a spark TextInput.
>>>>
>>>> I will continue to investigate.
>>>>
>>>>
>>>> Le 02/11/13 15:35, Alex Harui a écrit :
>>>>> Is this mx TextInput or Spark? Spark might be managing some undo
>>>>> stack
>>>>> or
>>>>> something like that.
>>>>>
>>>>> A good test is to build an AS-only equivalent and see if there is
>>>>> still
>>>>> a
>>>>> problem.
>>>>>
>>>>> -Alex
>>>>>
>>>>> On 11/2/13 4:11 AM, "After24" <vi...@after24.net> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I found out that the memory leak is caused by the focus manager.
>>>>>>
>>>>>> So concerning the warning about the module calling
>>>>>> net.registerClassAlias()
>>>>>> -> the module is garbage collected even when those warnings pops up
>>>>>> in
>>>>>> the
>>>>>> console.
>>>>>>
>>>>>> Now I'm stuck with the focus manager causing a memory leak :
>>>>>>
>>>>>> After reading some blog posts about the correct way to handle module
>>>>>> unloading (From Alex Harui ,Tom Sugden) I added a textInput in the
>>>>>> shell
>>>>>> application to which I give focus just before module unloading :
>>>>>> Now if a module button is clicked or if the focus is given to a
>>>>>> textinput
>>>>>> without typing anything, the module instance disappears when the run
>>>>>> Garbage
>>>>>> collector button is pressed but if some text is typed in a textInput
>>>>>> the
>>>>>> module stays in memory.
>>>>>> I used the debugger to see if the focusManager instance keeps a
>>>>>> reference
>>>>>> to
>>>>>> a module control but I don't found anything.
>>>>>>
>>>>>> Any idea ?
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>>
>>>>>>
>>>>>> http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management
>>>>>> -i
>>>>>> n-
>>>>>> modules-tp3422p3482.html
>>>>>> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>
Re: Memory leaks management in modules
Posted by Alex Harui <ah...@adobe.com>.
Switch to mx:TextInputs and/or TextField and see if the problem persists.
It could be that TLF sets up the flash.text.engine classes in a way that
references are kept to TextLines and/or their containers.
-Alex
On 11/2/13 8:53 AM, "After24" <vi...@after24.net> wrote:
>The main app contains the TextInput to wich I give focus before
>unloading the module. I replaced it with a button but it changes nothing.
>
>I tried the pure actionScript version with a textflow. I added to the
>flowComposer a ContainerController based on a sprite. Unfortunatly, the
>module is not garbage collected.
>
>Le 02/11/13 16:20, Alex Harui a écrit :
>> Are there Spark Text controls in the main app? If so, there could be
>>some
>> static vars in TLF that hang onto the control in the module.
>>
>> On 11/2/13 8:05 AM, "After24" <vi...@after24.net> wrote:
>>
>>> Hi Alex,
>>>
>>> Thank you very much.
>>> It's a spark TextInput.
>>>
>>> I will continue to investigate.
>>>
>>>
>>> Le 02/11/13 15:35, Alex Harui a écrit :
>>>> Is this mx TextInput or Spark? Spark might be managing some undo
>>>>stack
>>>> or
>>>> something like that.
>>>>
>>>> A good test is to build an AS-only equivalent and see if there is
>>>>still
>>>> a
>>>> problem.
>>>>
>>>> -Alex
>>>>
>>>> On 11/2/13 4:11 AM, "After24" <vi...@after24.net> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I found out that the memory leak is caused by the focus manager.
>>>>>
>>>>> So concerning the warning about the module calling
>>>>> net.registerClassAlias()
>>>>> -> the module is garbage collected even when those warnings pops up
>>>>>in
>>>>> the
>>>>> console.
>>>>>
>>>>> Now I'm stuck with the focus manager causing a memory leak :
>>>>>
>>>>> After reading some blog posts about the correct way to handle module
>>>>> unloading (From Alex Harui ,Tom Sugden) I added a textInput in the
>>>>> shell
>>>>> application to which I give focus just before module unloading :
>>>>> Now if a module button is clicked or if the focus is given to a
>>>>> textinput
>>>>> without typing anything, the module instance disappears when the run
>>>>> Garbage
>>>>> collector button is pressed but if some text is typed in a textInput
>>>>> the
>>>>> module stays in memory.
>>>>> I used the debugger to see if the focusManager instance keeps a
>>>>> reference
>>>>> to
>>>>> a module control but I don't found anything.
>>>>>
>>>>> Any idea ?
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>>
>>>>>
>>>>>http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management
>>>>>-i
>>>>> n-
>>>>> modules-tp3422p3482.html
>>>>> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>>
>
Re: Memory leaks management in modules
Posted by After24 <vi...@after24.net>.
The main app contains the TextInput to wich I give focus before
unloading the module. I replaced it with a button but it changes nothing.
I tried the pure actionScript version with a textflow. I added to the
flowComposer a ContainerController based on a sprite. Unfortunatly, the
module is not garbage collected.
Le 02/11/13 16:20, Alex Harui a écrit :
> Are there Spark Text controls in the main app? If so, there could be some
> static vars in TLF that hang onto the control in the module.
>
> On 11/2/13 8:05 AM, "After24" <vi...@after24.net> wrote:
>
>> Hi Alex,
>>
>> Thank you very much.
>> It's a spark TextInput.
>>
>> I will continue to investigate.
>>
>>
>> Le 02/11/13 15:35, Alex Harui a écrit :
>>> Is this mx TextInput or Spark? Spark might be managing some undo stack
>>> or
>>> something like that.
>>>
>>> A good test is to build an AS-only equivalent and see if there is still
>>> a
>>> problem.
>>>
>>> -Alex
>>>
>>> On 11/2/13 4:11 AM, "After24" <vi...@after24.net> wrote:
>>>
>>>> Hello,
>>>>
>>>> I found out that the memory leak is caused by the focus manager.
>>>>
>>>> So concerning the warning about the module calling
>>>> net.registerClassAlias()
>>>> -> the module is garbage collected even when those warnings pops up in
>>>> the
>>>> console.
>>>>
>>>> Now I'm stuck with the focus manager causing a memory leak :
>>>>
>>>> After reading some blog posts about the correct way to handle module
>>>> unloading (From Alex Harui ,Tom Sugden) I added a textInput in the
>>>> shell
>>>> application to which I give focus just before module unloading :
>>>> Now if a module button is clicked or if the focus is given to a
>>>> textinput
>>>> without typing anything, the module instance disappears when the run
>>>> Garbage
>>>> collector button is pressed but if some text is typed in a textInput
>>>> the
>>>> module stays in memory.
>>>> I used the debugger to see if the focusManager instance keeps a
>>>> reference
>>>> to
>>>> a module control but I don't found anything.
>>>>
>>>> Any idea ?
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>>
>>>> http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management-i
>>>> n-
>>>> modules-tp3422p3482.html
>>>> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>
Re: Memory leaks management in modules
Posted by Alex Harui <ah...@adobe.com>.
Are there Spark Text controls in the main app? If so, there could be some
static vars in TLF that hang onto the control in the module.
On 11/2/13 8:05 AM, "After24" <vi...@after24.net> wrote:
>Hi Alex,
>
>Thank you very much.
>It's a spark TextInput.
>
>I will continue to investigate.
>
>
>Le 02/11/13 15:35, Alex Harui a écrit :
>> Is this mx TextInput or Spark? Spark might be managing some undo stack
>>or
>> something like that.
>>
>> A good test is to build an AS-only equivalent and see if there is still
>>a
>> problem.
>>
>> -Alex
>>
>> On 11/2/13 4:11 AM, "After24" <vi...@after24.net> wrote:
>>
>>> Hello,
>>>
>>> I found out that the memory leak is caused by the focus manager.
>>>
>>> So concerning the warning about the module calling
>>> net.registerClassAlias()
>>> -> the module is garbage collected even when those warnings pops up in
>>>the
>>> console.
>>>
>>> Now I'm stuck with the focus manager causing a memory leak :
>>>
>>> After reading some blog posts about the correct way to handle module
>>> unloading (From Alex Harui ,Tom Sugden) I added a textInput in the
>>>shell
>>> application to which I give focus just before module unloading :
>>> Now if a module button is clicked or if the focus is given to a
>>>textinput
>>> without typing anything, the module instance disappears when the run
>>> Garbage
>>> collector button is pressed but if some text is typed in a textInput
>>>the
>>> module stays in memory.
>>> I used the debugger to see if the focusManager instance keeps a
>>>reference
>>> to
>>> a module control but I don't found anything.
>>>
>>> Any idea ?
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>>
>>>http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management-i
>>>n-
>>> modules-tp3422p3482.html
>>> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>>
>
Re: Memory leaks management in modules
Posted by After24 <vi...@after24.net>.
Hi Alex,
Thank you very much.
It's a spark TextInput.
I will continue to investigate.
Le 02/11/13 15:35, Alex Harui a écrit :
> Is this mx TextInput or Spark? Spark might be managing some undo stack or
> something like that.
>
> A good test is to build an AS-only equivalent and see if there is still a
> problem.
>
> -Alex
>
> On 11/2/13 4:11 AM, "After24" <vi...@after24.net> wrote:
>
>> Hello,
>>
>> I found out that the memory leak is caused by the focus manager.
>>
>> So concerning the warning about the module calling
>> net.registerClassAlias()
>> -> the module is garbage collected even when those warnings pops up in the
>> console.
>>
>> Now I'm stuck with the focus manager causing a memory leak :
>>
>> After reading some blog posts about the correct way to handle module
>> unloading (From Alex Harui ,Tom Sugden) I added a textInput in the shell
>> application to which I give focus just before module unloading :
>> Now if a module button is clicked or if the focus is given to a textinput
>> without typing anything, the module instance disappears when the run
>> Garbage
>> collector button is pressed but if some text is typed in a textInput the
>> module stays in memory.
>> I used the debugger to see if the focusManager instance keeps a reference
>> to
>> a module control but I don't found anything.
>>
>> Any idea ?
>>
>>
>>
>> --
>> View this message in context:
>> http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management-in-
>> modules-tp3422p3482.html
>> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>
Re: Memory leaks management in modules
Posted by Alex Harui <ah...@adobe.com>.
Is this mx TextInput or Spark? Spark might be managing some undo stack or
something like that.
A good test is to build an AS-only equivalent and see if there is still a
problem.
-Alex
On 11/2/13 4:11 AM, "After24" <vi...@after24.net> wrote:
>Hello,
>
>I found out that the memory leak is caused by the focus manager.
>
>So concerning the warning about the module calling
>net.registerClassAlias()
>-> the module is garbage collected even when those warnings pops up in the
>console.
>
>Now I'm stuck with the focus manager causing a memory leak :
>
>After reading some blog posts about the correct way to handle module
>unloading (From Alex Harui ,Tom Sugden) I added a textInput in the shell
>application to which I give focus just before module unloading :
>Now if a module button is clicked or if the focus is given to a textinput
>without typing anything, the module instance disappears when the run
>Garbage
>collector button is pressed but if some text is typed in a textInput the
>module stays in memory.
>I used the debugger to see if the focusManager instance keeps a reference
>to
>a module control but I don't found anything.
>
>Any idea ?
>
>
>
>--
>View this message in context:
>http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management-in-
>modules-tp3422p3482.html
>Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Memory leaks management in modules
Posted by After24 <vi...@after24.net>.
Hello,
I found out that the memory leak is caused by the focus manager.
So concerning the warning about the module calling net.registerClassAlias()
-> the module is garbage collected even when those warnings pops up in the
console.
Now I'm stuck with the focus manager causing a memory leak :
After reading some blog posts about the correct way to handle module
unloading (From Alex Harui ,Tom Sugden) I added a textInput in the shell
application to which I give focus just before module unloading :
Now if a module button is clicked or if the focus is given to a textinput
without typing anything, the module instance disappears when the run Garbage
collector button is pressed but if some text is typed in a textInput the
module stays in memory.
I used the debugger to see if the focusManager instance keeps a reference to
a module control but I don't found anything.
Any idea ?
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management-in-modules-tp3422p3482.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Memory leaks management in modules
Posted by After24 <vi...@after24.net>.
Darrell,
Forcing the main application to register class aliases at start up
remove the warnings but apparently not the memory leak : the profiler
still show one occurence of the module even when it has been unloaded
and the "run garbage collector" button is pressed. I will continue to
investigate to find out if the memory leak is caused by something else
in my code (event listener etc.)
Thank you for your time.
Le 31/10/13 19:28, Darrell Loverin a écrit :
> I was wrong about the warning being removed in the compiler. It's still in
> the ApacheFlex code. Did you confirm that the module was actually leaking
> or just concerned about the warning? BTW the warning is only compiled into
> the application when the application is compiled for debug.
>
>
> @Alex, do you remember this issue and if it was fixed in the Flash Player.
>
>
> -Darrell
>
>
>
> On Thu, Oct 31, 2013 at 12:36 PM, After24 <vi...@after24.net> wrote:
>
>> Darrell.
>>
>> I tried differents settings in the Flex Compiler panel of the main
>> application property window :
>>
>> SDK 4.6, 4.10, 4.11 -> warnings show up in the console
>> SDK 4.5.1 -> warnings are replaced by "null"
>>
>> Do you have an idea of the way I can get rid of these warnings without
>> unchecking "enable warnings" in the compiler options panel ?
>>
>> Thank you.
>>
>> Vincent.
>>
>>
>> Le 31/10/13 16:27, Darrell Loverin a écrit :
>>
>> Does that mean that the warning shouldn't show up in the console ?
>>>> I means you are using a compiler that it detecting the leak scenario and
>>> generating the warning based on the assumed Flash Player issue.
>>>
>>>
>>> -Darrell
>>>
>>>
>>> On Thu, Oct 31, 2013 at 9:50 AM, After24 <vi...@after24.net> wrote:
>>>
>>> Hello Darrell,
>>>> Thank you for you answer.
>>>>
>>>> when you say
>>>> Darrell Loverin-2 wrote
>>>>
>>>>> So I think it is safe to ignore the warning which I believe was removed
>>>>> from the SDK (don't know the version)
>>>>>
>>>> Does that mean that the warning shouldn't show up in the console ?
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://apache-flex-users.**2333346.n4.nabble.com/Memory-**
>>>> leaks-management-in-modules-**tp3422p3429.html<http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management-in-modules-tp3422p3429.html>
>>>> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>>>>
>>>>
Re: Memory leaks management in modules
Posted by Darrell Loverin <da...@gmail.com>.
I was wrong about the warning being removed in the compiler. It's still in
the ApacheFlex code. Did you confirm that the module was actually leaking
or just concerned about the warning? BTW the warning is only compiled into
the application when the application is compiled for debug.
@Alex, do you remember this issue and if it was fixed in the Flash Player.
-Darrell
On Thu, Oct 31, 2013 at 12:36 PM, After24 <vi...@after24.net> wrote:
> Darrell.
>
> I tried differents settings in the Flex Compiler panel of the main
> application property window :
>
> SDK 4.6, 4.10, 4.11 -> warnings show up in the console
> SDK 4.5.1 -> warnings are replaced by "null"
>
> Do you have an idea of the way I can get rid of these warnings without
> unchecking "enable warnings" in the compiler options panel ?
>
> Thank you.
>
> Vincent.
>
>
> Le 31/10/13 16:27, Darrell Loverin a écrit :
>
> Does that mean that the warning shouldn't show up in the console ?
>>>>
>>> I means you are using a compiler that it detecting the leak scenario and
>> generating the warning based on the assumed Flash Player issue.
>>
>>
>> -Darrell
>>
>>
>> On Thu, Oct 31, 2013 at 9:50 AM, After24 <vi...@after24.net> wrote:
>>
>> Hello Darrell,
>>>
>>> Thank you for you answer.
>>>
>>> when you say
>>> Darrell Loverin-2 wrote
>>>
>>>> So I think it is safe to ignore the warning which I believe was removed
>>>> from the SDK (don't know the version)
>>>>
>>> Does that mean that the warning shouldn't show up in the console ?
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://apache-flex-users.**2333346.n4.nabble.com/Memory-**
>>> leaks-management-in-modules-**tp3422p3429.html<http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management-in-modules-tp3422p3429.html>
>>> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>>>
>>>
>
Re: Memory leaks management in modules
Posted by After24 <vi...@after24.net>.
Darrell.
I tried differents settings in the Flex Compiler panel of the main
application property window :
SDK 4.6, 4.10, 4.11 -> warnings show up in the console
SDK 4.5.1 -> warnings are replaced by "null"
Do you have an idea of the way I can get rid of these warnings without
unchecking "enable warnings" in the compiler options panel ?
Thank you.
Vincent.
Le 31/10/13 16:27, Darrell Loverin a écrit :
>>> Does that mean that the warning shouldn't show up in the console ?
> I means you are using a compiler that it detecting the leak scenario and
> generating the warning based on the assumed Flash Player issue.
>
>
> -Darrell
>
>
> On Thu, Oct 31, 2013 at 9:50 AM, After24 <vi...@after24.net> wrote:
>
>> Hello Darrell,
>>
>> Thank you for you answer.
>>
>> when you say
>> Darrell Loverin-2 wrote
>>> So I think it is safe to ignore the warning which I believe was removed
>>> from the SDK (don't know the version)
>> Does that mean that the warning shouldn't show up in the console ?
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management-in-modules-tp3422p3429.html
>> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>>
Re: Memory leaks management in modules
Posted by Darrell Loverin <da...@gmail.com>.
>>Does that mean that the warning shouldn't show up in the console ?
I means you are using a compiler that it detecting the leak scenario and
generating the warning based on the assumed Flash Player issue.
-Darrell
On Thu, Oct 31, 2013 at 9:50 AM, After24 <vi...@after24.net> wrote:
> Hello Darrell,
>
> Thank you for you answer.
>
> when you say
> Darrell Loverin-2 wrote
> > So I think it is safe to ignore the warning which I believe was removed
> > from the SDK (don't know the version)
>
> Does that mean that the warning shouldn't show up in the console ?
>
>
>
>
> --
> View this message in context:
> http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management-in-modules-tp3422p3429.html
> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>
Re: Memory leaks management in modules
Posted by Cosma Colanicchia <co...@gmail.com>.
If I remember well, each SecurityDomain has its own class alias registry
since Flash Player 10.1
2013/10/31 After24 <vi...@after24.net>
> Hello Darrell,
>
> Thank you for you answer.
>
> when you say
> Darrell Loverin-2 wrote
> > So I think it is safe to ignore the warning which I believe was removed
> > from the SDK (don't know the version)
>
> Does that mean that the warning shouldn't show up in the console ?
>
>
>
>
> --
> View this message in context:
> http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management-in-modules-tp3422p3429.html
> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>
Re: Memory leaks management in modules
Posted by After24 <vi...@after24.net>.
Hello Darrell,
Thank you for you answer.
when you say
Darrell Loverin-2 wrote
> So I think it is safe to ignore the warning which I believe was removed
> from the SDK (don't know the version)
Does that mean that the warning shouldn't show up in the console ?
--
View this message in context: http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management-in-modules-tp3422p3429.html
Sent from the Apache Flex Users mailing list archive at Nabble.com.
Re: Memory leaks management in modules
Posted by Darrell Loverin <da...@gmail.com>.
So I think it is safe to ignore the warning which I believe was removed
from the SDK (don't know the version).
-Darrell
On Thu, Oct 31, 2013 at 9:31 AM, Darrell Loverin
<da...@gmail.com>wrote:
> I believe this leaked was fixed in the Flash Player but I'm not sure which
> version.
>
>
> On Thu, Oct 31, 2013 at 7:20 AM, After24 <vi...@after24.net> wrote:
>
>> Hello list,
>>
>> I'm working on a modular application where all services and value objects
>> are stored in a RSL. The inconvenient with this organization is that when
>> a
>> value object alias is registered by a module during an AMF call it cause a
>> memory leak revealed by a console warning :
>>
>> warning: The class myValueObject has been used in a call to
>> net.registerClassAlias() in _myModule_FlexInit. This will cause myModule
>> to
>> be leaked. To resolve the leak, define myValueObject in the top-level
>> application.
>>
>> I want my value objects to be in a RSL so my workaround is to force the
>> main
>> application to register the alias of all VO's at startup in a loop :
>>
>> public function RegisterClasses()
>> {
>> var classDefinitions:Vector.<String> =
>> ApplicationDomain.currentDomain.getQualifiedDefinitionNames();
>>
>> for (var i:int = 0; i < classDefinitions.length;
>> i++)
>> {
>> if
>> (classDefinitions[i].indexOf("fr.mydomain.core.vo") >= 0)
>> {
>> var aliasName:String =
>> String(classDefinitions[i].split(".").pop()).replace("::", ".");
>> registerClassAlias(aliasName,
>> getDefinitionByName(classDefinitions[i])
>> as Class);
>> }
>> }
>> }
>>
>> It works but if anyone found a better way to handle this issue I would be
>> glad to hear how.
>>
>> Thanks.
>>
>>
>>
>> --
>> View this message in context:
>> http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management-in-modules-tp3422.html
>> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>>
>
>
Re: Memory leaks management in modules
Posted by Darrell Loverin <da...@gmail.com>.
I believe this leaked was fixed in the Flash Player but I'm not sure which
version.
On Thu, Oct 31, 2013 at 7:20 AM, After24 <vi...@after24.net> wrote:
> Hello list,
>
> I'm working on a modular application where all services and value objects
> are stored in a RSL. The inconvenient with this organization is that when a
> value object alias is registered by a module during an AMF call it cause a
> memory leak revealed by a console warning :
>
> warning: The class myValueObject has been used in a call to
> net.registerClassAlias() in _myModule_FlexInit. This will cause myModule to
> be leaked. To resolve the leak, define myValueObject in the top-level
> application.
>
> I want my value objects to be in a RSL so my workaround is to force the
> main
> application to register the alias of all VO's at startup in a loop :
>
> public function RegisterClasses()
> {
> var classDefinitions:Vector.<String> =
> ApplicationDomain.currentDomain.getQualifiedDefinitionNames();
>
> for (var i:int = 0; i < classDefinitions.length;
> i++)
> {
> if
> (classDefinitions[i].indexOf("fr.mydomain.core.vo") >= 0)
> {
> var aliasName:String =
> String(classDefinitions[i].split(".").pop()).replace("::", ".");
> registerClassAlias(aliasName,
> getDefinitionByName(classDefinitions[i])
> as Class);
> }
> }
> }
>
> It works but if anyone found a better way to handle this issue I would be
> glad to hear how.
>
> Thanks.
>
>
>
> --
> View this message in context:
> http://apache-flex-users.2333346.n4.nabble.com/Memory-leaks-management-in-modules-tp3422.html
> Sent from the Apache Flex Users mailing list archive at Nabble.com.
>