At least one memory leak problem is a custom combo box I use.

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

At least one memory leak problem is a custom combo box I use.

Paul Stearns
Alex:

I have found that using a custom combo box I built causes the module that contains it to stay in memory.

If I create a new instance but do not access it, everything is fine, As soon as I touch the dataprovider, it will not allow the parent module to unload (even if I set the dataProvider to null). I changed it to a standard combobox, and everything is ducky, but that doesn't have the features I need.

If you could take a look at my ValidatedComboBox function and see if it is something obvious, I'd appreciate it.

https://pastebin.com/HyMTCC1Y

Paul R. Stearns
Advanced Consulting Enterprises, Inc.

15280 NW 79th Ct.
Suite 250
Miami Lakes, Fl 33016

Voice: (305)623-0360 x107
Fax: (305)623-4588


Reply | Threaded
Open this post in threaded view
|

Re: At least one memory leak problem is a custom combo box I use.

Alex Harui-2
Hard to say for sure, but one thing to watch out for with ComboBox is running any code that accesses the dropdown property.    ComboBox by itself should know how to destroy and unhook the dropdown, but if you run code that access dropDown after ComboBox thinks it cleaned up, then it will get stuck in memory again.

HTH,
-Alex

On 2/1/19, 10:19 PM, "Paul Stearns" <[hidden email]> wrote:

    Alex:
   
    I have found that using a custom combo box I built causes the module that contains it to stay in memory.
   
    If I create a new instance but do not access it, everything is fine, As soon as I touch the dataprovider, it will not allow the parent module to unload (even if I set the dataProvider to null). I changed it to a standard combobox, and everything is ducky, but that doesn't have the features I need.
   
    If you could take a look at my ValidatedComboBox function and see if it is something obvious, I'd appreciate it.
   
    https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2FHyMTCC1Y&amp;data=02%7C01%7Caharui%40adobe.com%7C231ee986cc774540946a08d688d65832%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636846851513368107&amp;sdata=tT4%2BqA90aBbCdypmr59FIGnRgyJFN72d42fKr75dRE0%3D&amp;reserved=0
   
    Paul R. Stearns
    Advanced Consulting Enterprises, Inc.
   
    15280 NW 79th Ct.
    Suite 250
    Miami Lakes, Fl 33016
   
    Voice: (305)623-0360 x107
    Fax: (305)623-4588
   
   
   

Reply | Threaded
Open this post in threaded view
|

Re: At least one memory leak problem is a custom combo box I use.

Mick Powell
Hello Paul,

I noticed a similar problem years ago in the flex 4.1 SDK, but it could have been there for a while before that. We used a pretty simple workaround that you could try: https://mickpowellstips.blogspot.com/2010/11/dropdownlist-memory-leak-flex-41.html. It might fix your issue, and I doubt it will do any harm to give it a whirl… There might be a better approach as well, but that was the way we solved it.

All the best,

Mick

> On Feb 2, 2019, at 12:55 AM, Alex Harui <[hidden email]> wrote:
>
> Hard to say for sure, but one thing to watch out for with ComboBox is running any code that accesses the dropdown property.    ComboBox by itself should know how to destroy and unhook the dropdown, but if you run code that access dropDown after ComboBox thinks it cleaned up, then it will get stuck in memory again.
>
> HTH,
> -Alex
>
> On 2/1/19, 10:19 PM, "Paul Stearns" <[hidden email]> wrote:
>
>    Alex:
>
>    I have found that using a custom combo box I built causes the module that contains it to stay in memory.
>
>    If I create a new instance but do not access it, everything is fine, As soon as I touch the dataprovider, it will not allow the parent module to unload (even if I set the dataProvider to null). I changed it to a standard combobox, and everything is ducky, but that doesn't have the features I need.
>
>    If you could take a look at my ValidatedComboBox function and see if it is something obvious, I'd appreciate it.
>
>    https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2FHyMTCC1Y&amp;data=02%7C01%7Caharui%40adobe.com%7C231ee986cc774540946a08d688d65832%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636846851513368107&amp;sdata=tT4%2BqA90aBbCdypmr59FIGnRgyJFN72d42fKr75dRE0%3D&amp;reserved=0
>
>    Paul R. Stearns
>    Advanced Consulting Enterprises, Inc.
>
>    15280 NW 79th Ct.
>    Suite 250
>    Miami Lakes, Fl 33016
>
>    Voice: (305)623-0360 x107
>    Fax: (305)623-4588
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: At least one memory leak problem is a custom combo box I use.

Paul Stearns
In reply to this post by Paul Stearns
Alex:

Yes this code does reference the DropDown component. The code is there to handle finding items and moving the cursor to the appropriate item.

For example if the data is;

dog
cat
bird

and c-a-t is typed it finds cat and highlights it.

If the data provider changes and the values become;

dog
lizard
cat
bird

the component will still keep cat highlighted.

Given the above as a requirement, how can I clear make the component eligible for GC?

Paul R. Stearns
Advanced Consulting Enterprises, Inc.

15280 NW 79th Ct.
Suite 250
Miami Lakes, Fl 33016

Voice: (305)623-0360 x107
Fax: (305)623-4588

----------------------------------------
From: Alex Harui <[hidden email]>
Sent: 2/2/19 1:55 AM
To: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: Re: At least one memory leak problem is a custom combo box I use.
Hard to say for sure, but one thing to watch out for with ComboBox is running any code that accesses the dropdown property. ComboBox by itself should know how to destroy and unhook the dropdown, but if you run code that access dropDown after ComboBox thinks it cleaned up, then it will get stuck in memory again.

HTH,
-Alex

On 2/1/19, 10:19 PM, "Paul Stearns" wrote:

Alex:

I have found that using a custom combo box I built causes the module that contains it to stay in memory.

If I create a new instance but do not access it, everything is fine, As soon as I touch the dataprovider, it will not allow the parent module to unload (even if I set the dataProvider to null). I changed it to a standard combobox, and everything is ducky, but that doesn't have the features I need.

If you could take a look at my ValidatedComboBox function and see if it is something obvious, I'd appreciate it.

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2FHyMTCC1Y&data=02%7C01%7Caharui%40adobe.com%7C231ee986cc774540946a08d688d65832%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636846851513368107&sdata=tT4%2BqA90aBbCdypmr59FIGnRgyJFN72d42fKr75dRE0%3D&reserved=0

Paul R. Stearns
Advanced Consulting Enterprises, Inc.

15280 NW 79th Ct.
Suite 250
Miami Lakes, Fl 33016

Voice: (305)623-0360 x107
Fax: (305)623-4588


Reply | Threaded
Open this post in threaded view
|

Re: At least one memory leak problem is a custom combo box I use.

Alex Harui-2
It is fine to access the dropDown property as long as it doesn't happen after other clean up code runs.

It might be worth debugging to see if the dropDown is the actual problem.  It could be something else, like some eventhandler that handles an event you dispatch from your code keeps a reference to the combobox.  So use the debugger  or profiler or other means to see if the dropdown is still on the display list.  You can report on the children in SystemManager.popUpChildren.  You can verify that the ComboBox's destroyDropdown is being called.  And then try to verify that dropDown is not accessed after that.

HTH,
-Alex

On 2/2/19, 1:43 PM, "Paul Stearns" <[hidden email]> wrote:

    Alex:
   
    Yes this code does reference the DropDown component. The code is there to handle finding items and moving the cursor to the appropriate item.
   
    For example if the data is;
   
    dog
    cat
    bird
   
    and c-a-t is typed it finds cat and highlights it.
   
    If the data provider changes and the values become;
   
    dog
    lizard
    cat
    bird
   
    the component will still keep cat highlighted.
   
    Given the above as a requirement, how can I clear make the component eligible for GC?
   
    Paul R. Stearns
    Advanced Consulting Enterprises, Inc.
   
    15280 NW 79th Ct.
    Suite 250
    Miami Lakes, Fl 33016
   
    Voice: (305)623-0360 x107
    Fax: (305)623-4588
   
    ----------------------------------------
    From: Alex Harui <[hidden email]>
    Sent: 2/2/19 1:55 AM
    To: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>
    Subject: Re: At least one memory leak problem is a custom combo box I use.
    Hard to say for sure, but one thing to watch out for with ComboBox is running any code that accesses the dropdown property. ComboBox by itself should know how to destroy and unhook the dropdown, but if you run code that access dropDown after ComboBox thinks it cleaned up, then it will get stuck in memory again.
   
    HTH,
    -Alex
   
    On 2/1/19, 10:19 PM, "Paul Stearns" wrote:
   
    Alex:
   
    I have found that using a custom combo box I built causes the module that contains it to stay in memory.
   
    If I create a new instance but do not access it, everything is fine, As soon as I touch the dataprovider, it will not allow the parent module to unload (even if I set the dataProvider to null). I changed it to a standard combobox, and everything is ducky, but that doesn't have the features I need.
   
    If you could take a look at my ValidatedComboBox function and see if it is something obvious, I'd appreciate it.
   
    https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2FHyMTCC1Y&amp;data=02%7C01%7Caharui%40adobe.com%7Cfb19977d8bca48a31d7708d6895783f6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636847406335722938&amp;sdata=ZQASYXvbPPMfWDk8kWtVTskwz1Z%2BPF7UVmXEWUBF%2Bek%3D&amp;reserved=0
   
    Paul R. Stearns
    Advanced Consulting Enterprises, Inc.
   
    15280 NW 79th Ct.
    Suite 250
    Miami Lakes, Fl 33016
   
    Voice: (305)623-0360 x107
    Fax: (305)623-4588
   
   
   

Reply | Threaded
Open this post in threaded view
|

Re: At least one memory leak problem is a custom combo box I use.

Paul Stearns
In reply to this post by Paul Stearns
Alex:

After I wrote my previous email, I changed the code to not access the dropdown. I was able to use "invalidateDisplayOptions," and use only the combobox items directly.

I am still debugging.

Paul R. Stearns
Advanced Consulting Enterprises, Inc.

15280 NW 79th Ct.
Suite 250
Miami Lakes, Fl 33016

Voice: (305)623-0360 x107
Fax: (305)623-4588

----------------------------------------
From: Alex Harui <[hidden email]>
Sent: 2/2/19 6:09 PM
To: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: Re: At least one memory leak problem is a custom combo box I use.
It is fine to access the dropDown property as long as it doesn't happen after other clean up code runs.

It might be worth debugging to see if the dropDown is the actual problem. It could be something else, like some eventhandler that handles an event you dispatch from your code keeps a reference to the combobox. So use the debugger or profiler or other means to see if the dropdown is still on the display list. You can report on the children in SystemManager.popUpChildren. You can verify that the ComboBox's destroyDropdown is being called. And then try to verify that dropDown is not accessed after that.

HTH,
-Alex

On 2/2/19, 1:43 PM, "Paul Stearns" wrote:

Alex:

Yes this code does reference the DropDown component. The code is there to handle finding items and moving the cursor to the appropriate item.

For example if the data is;

dog
cat
bird

and c-a-t is typed it finds cat and highlights it.

If the data provider changes and the values become;

dog
lizard
cat
bird

the component will still keep cat highlighted.

Given the above as a requirement, how can I clear make the component eligible for GC?

Paul R. Stearns
Advanced Consulting Enterprises, Inc.

15280 NW 79th Ct.
Suite 250
Miami Lakes, Fl 33016

Voice: (305)623-0360 x107
Fax: (305)623-4588

----------------------------------------
From: Alex Harui
Sent: 2/2/19 1:55 AM
To: "[hidden email]" , "[hidden email]"
Subject: Re: At least one memory leak problem is a custom combo box I use.
Hard to say for sure, but one thing to watch out for with ComboBox is running any code that accesses the dropdown property. ComboBox by itself should know how to destroy and unhook the dropdown, but if you run code that access dropDown after ComboBox thinks it cleaned up, then it will get stuck in memory again.

HTH,
-Alex

On 2/1/19, 10:19 PM, "Paul Stearns" wrote:

Alex:

I have found that using a custom combo box I built causes the module that contains it to stay in memory.

If I create a new instance but do not access it, everything is fine, As soon as I touch the dataprovider, it will not allow the parent module to unload (even if I set the dataProvider to null). I changed it to a standard combobox, and everything is ducky, but that doesn't have the features I need.

If you could take a look at my ValidatedComboBox function and see if it is something obvious, I'd appreciate it.

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2FHyMTCC1Y&data=02%7C01%7Caharui%40adobe.com%7Cfb19977d8bca48a31d7708d6895783f6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636847406335722938&sdata=ZQASYXvbPPMfWDk8kWtVTskwz1Z%2BPF7UVmXEWUBF%2Bek%3D&reserved=0

Paul R. Stearns
Advanced Consulting Enterprises, Inc.

15280 NW 79th Ct.
Suite 250
Miami Lakes, Fl 33016

Voice: (305)623-0360 x107
Fax: (305)623-4588


Reply | Threaded
Open this post in threaded view
|

Re: At least one memory leak problem is a custom combo box I use.

Alex Harui-2
Paul:

I assume that means that your custom combobox is still causing a memory leak?

IIRC, you have a test setup where you click a button to unload the module.  Add another button that checks the number of children of systemManager.popupChildren.numChildren.  That number should go up by one when the dropdown is accessed and go down by one after the module cleans up to try to unload.  If it does go down by one, then the dropdown is probably going away and is not the problem.  If it is there, then some code may still be accessing the dropdown property.  Maybe override the dropdown property getter and trace who is accessing it.

HTH,
-Alex

From: Paul Stearns <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Saturday, February 2, 2019 at 3:22 PM
To: Alex Harui <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: Re: At least one memory leak problem is a custom combo box I use.

Alex:

After I wrote my previous email, I changed the code to not access the dropdown. I was able to use "invalidateDisplayOptions," and use only the combobox items directly.

I am still debugging.


Paul R. Stearns
Advanced Consulting Enterprises, Inc.

15280 NW 79th Ct.
Suite 250
Miami Lakes, Fl 33016

Voice: (305)623-0360 x107
Fax: (305)623-4588

________________________________
From: Alex Harui <[hidden email]>
Sent: 2/2/19 6:09 PM
To: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: Re: At least one memory leak problem is a custom combo box I use.
It is fine to access the dropDown property as long as it doesn't happen after other clean up code runs.

It might be worth debugging to see if the dropDown is the actual problem. It could be something else, like some eventhandler that handles an event you dispatch from your code keeps a reference to the combobox. So use the debugger or profiler or other means to see if the dropdown is still on the display list. You can report on the children in SystemManager.popUpChildren. You can verify that the ComboBox's destroyDropdown is being called. And then try to verify that dropDown is not accessed after that.

HTH,
-Alex

On 2/2/19, 1:43 PM, "Paul Stearns" wrote:

Alex:

Yes this code does reference the DropDown component. The code is there to handle finding items and moving the cursor to the appropriate item.

For example if the data is;

dog
cat
bird

and c-a-t is typed it finds cat and highlights it.

If the data provider changes and the values become;

dog
lizard
cat
bird

the component will still keep cat highlighted.

Given the above as a requirement, how can I clear make the component eligible for GC?

Paul R. Stearns
Advanced Consulting Enterprises, Inc.

15280 NW 79th Ct.
Suite 250
Miami Lakes, Fl 33016

Voice: (305)623-0360 x107
Fax: (305)623-4588

----------------------------------------
From: Alex Harui
Sent: 2/2/19 1:55 AM
To: "[hidden email]" , "[hidden email]"
Subject: Re: At least one memory leak problem is a custom combo box I use.
Hard to say for sure, but one thing to watch out for with ComboBox is running any code that accesses the dropdown property. ComboBox by itself should know how to destroy and unhook the dropdown, but if you run code that access dropDown after ComboBox thinks it cleaned up, then it will get stuck in memory again.

HTH,
-Alex

On 2/1/19, 10:19 PM, "Paul Stearns" wrote:

Alex:

I have found that using a custom combo box I built causes the module that contains it to stay in memory.

If I create a new instance but do not access it, everything is fine, As soon as I touch the dataprovider, it will not allow the parent module to unload (even if I set the dataProvider to null). I changed it to a standard combobox, and everything is ducky, but that doesn't have the features I need.

If you could take a look at my ValidatedComboBox function and see if it is something obvious, I'd appreciate it.

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2FHyMTCC1Y&data=02%7C01%7Caharui%40adobe.com%7Cfb19977d8bca48a31d7708d6895783f6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636847406335722938&sdata=ZQASYXvbPPMfWDk8kWtVTskwz1Z%2BPF7UVmXEWUBF%2Bek%3D&reserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2FHyMTCC1Y&data=02%7C01%7Caharui%40adobe.com%7C95812d28fc8448ab546e08d68965586a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636847465737266976&sdata=SfzaMWFKwc2oyAl5Vm%2B%2BYDWQPNnP%2FqFK9xnBxgeeOWQ%3D&reserved=0>

Paul R. Stearns
Advanced Consulting Enterprises, Inc.

15280 NW 79th Ct.
Suite 250
Miami Lakes, Fl 33016

Voice: (305)623-0360 x107
Fax: (305)623-4588




Reply | Threaded
Open this post in threaded view
|

Re: At least one memory leak problem is a custom combo box I use.

Paul Stearns
In reply to this post by Paul Stearns
Alex:

I should have been more clear. The validatedCombobox no longer appears to keep my test module in memory. By replacing access to the dropdown, and relying on invalidateDisplayOptions to synchronize everything seems to work.

I also found something else that appears to be causing a problem, that I have started to correct.

This is a fairly complex DB application with hundreds of tables, 30-40 of which are generally used to populate combo boxes and other list components. These tables are fairly static and up to 15-20 could be used in a single entry screen.

In order to reduce network thrashing between the DB and the client computers, I wrote a public function that resides in the parent Application called loadComboList. When a request is made for this type of data in memory array collections are checked first, if they are null it then queries the DB, returns the data to the application to both be stored in globally accessible array collections, cloned and sent to the requesting module. If the data is in an array collection it is just cloned and sent back to the requesting module.

The modules handle all this by passing a "call back function" to the parentApplication function, which is then stored in a "private var". This parentApplication private var never gets cleared so it is a reference to a public function in the module causing the module to not be GCed. Not the smartest code I ever wrote, (hindsight is 20/20) but it does make things run faster, until the memory leak wreaks havoc.

I have started to rewrite this as a class which is instantiated in the module, but stores/reads its data in/from the parent application. I have tested it with a small live module (one query/combobox) and it seems to work. I am converting another 18 queries to test a much larger module, I will keep you posted, if you are interested.

Paul R. Stearns
Advanced Consulting Enterprises, Inc.

15280 NW 79th Ct.
Suite 250
Miami Lakes, Fl 33016

Voice: (305)623-0360 x107
Fax: (305)623-4588

----------------------------------------
From: Alex Harui <[hidden email]>
Sent: 2/2/19 7:46 PM
To: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: Re: At least one memory leak problem is a custom combo box I use.
Paul:

I assume that means that your custom combobox is still causing a memory leak?

IIRC, you have a test setup where you click a button to unload the module. Add another button that checks the number of children of systemManager.popupChildren.numChildren. That number should go up by one when the dropdown is accessed and go down by one after the module cleans up to try to unload. If it does go down by one, then the dropdown is probably going away and is not the problem. If it is there, then some code may still be accessing the dropdown property. Maybe override the dropdown property getter and trace who is accessing it.

HTH,
-Alex

From: Paul Stearns
Reply-To: "[hidden email]"
Date: Saturday, February 2, 2019 at 3:22 PM
To: Alex Harui , "[hidden email]"
Subject: Re: At least one memory leak problem is a custom combo box I use.

Alex:

After I wrote my previous email, I changed the code to not access the dropdown. I was able to use "invalidateDisplayOptions," and use only the combobox items directly.

I am still debugging.

Paul R. Stearns
Advanced Consulting Enterprises, Inc.

15280 NW 79th Ct.
Suite 250
Miami Lakes, Fl 33016

Voice: (305)623-0360 x107
Fax: (305)623-4588

________________________________
From: Alex Harui
Sent: 2/2/19 6:09 PM
To: "[hidden email]" , "[hidden email]"
Subject: Re: At least one memory leak problem is a custom combo box I use.
It is fine to access the dropDown property as long as it doesn't happen after other clean up code runs.

It might be worth debugging to see if the dropDown is the actual problem. It could be something else, like some eventhandler that handles an event you dispatch from your code keeps a reference to the combobox. So use the debugger or profiler or other means to see if the dropdown is still on the display list. You can report on the children in SystemManager.popUpChildren. You can verify that the ComboBox's destroyDropdown is being called. And then try to verify that dropDown is not accessed after that.

HTH,
-Alex

On 2/2/19, 1:43 PM, "Paul Stearns" wrote:

Alex:

Yes this code does reference the DropDown component. The code is there to handle finding items and moving the cursor to the appropriate item.

For example if the data is;

dog
cat
bird

and c-a-t is typed it finds cat and highlights it.

If the data provider changes and the values become;

dog
lizard
cat
bird

the component will still keep cat highlighted.

Given the above as a requirement, how can I clear make the component eligible for GC?

Paul R. Stearns
Advanced Consulting Enterprises, Inc.

15280 NW 79th Ct.
Suite 250
Miami Lakes, Fl 33016

Voice: (305)623-0360 x107
Fax: (305)623-4588

----------------------------------------
From: Alex Harui
Sent: 2/2/19 1:55 AM
To: "[hidden email]" , "[hidden email]"
Subject: Re: At least one memory leak problem is a custom combo box I use.
Hard to say for sure, but one thing to watch out for with ComboBox is running any code that accesses the dropdown property. ComboBox by itself should know how to destroy and unhook the dropdown, but if you run code that access dropDown after ComboBox thinks it cleaned up, then it will get stuck in memory again.

HTH,
-Alex

On 2/1/19, 10:19 PM, "Paul Stearns" wrote:

Alex:

I have found that using a custom combo box I built causes the module that contains it to stay in memory.

If I create a new instance but do not access it, everything is fine, As soon as I touch the dataprovider, it will not allow the parent module to unload (even if I set the dataProvider to null). I changed it to a standard combobox, and everything is ducky, but that doesn't have the features I need.

If you could take a look at my ValidatedComboBox function and see if it is something obvious, I'd appreciate it.

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2FHyMTCC1Y&data=02%7C01%7Caharui%40adobe.com%7Cfb19977d8bca48a31d7708d6895783f6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636847406335722938&sdata=ZQASYXvbPPMfWDk8kWtVTskwz1Z%2BPF7UVmXEWUBF%2Bek%3D&reserved=0

Paul R. Stearns
Advanced Consulting Enterprises, Inc.

15280 NW 79th Ct.
Suite 250
Miami Lakes, Fl 33016

Voice: (305)623-0360 x107
Fax: (305)623-4588


Reply | Threaded
Open this post in threaded view
|

Re: At least one memory leak problem is a custom combo box I use.

Alex Harui-2
Paul:

OK, good to know you got past one issue.

FWIW, storing callbacks from the module is what I call "reaching down".  The main app has effectively reached down into the module and grabbed hold of something.  The pattern closest to callbacks is event dispatching and event dispatching has the advantage of supporting weak-reference listeners.  You could try storing callbacks in weak-reference dictionaries as well if you are trying to find a minimal refactor.

HTH,
-Alex

On 2/2/19, 5:25 PM, "Paul Stearns" <[hidden email]> wrote:

    Alex:
   
    I should have been more clear. The validatedCombobox no longer appears to keep my test module in memory. By replacing access to the dropdown, and relying on invalidateDisplayOptions to synchronize everything seems to work.
   
    I also found something else that appears to be causing a problem, that I have started to correct.
   
    This is a fairly complex DB application with hundreds of tables, 30-40 of which are generally used to populate combo boxes and other list components. These tables are fairly static and up to 15-20 could be used in a single entry screen.
   
    In order to reduce network thrashing between the DB and the client computers, I wrote a public function that resides in the parent Application called loadComboList. When a request is made for this type of data in memory array collections are checked first, if they are null it then queries the DB, returns the data to the application to both be stored in globally accessible array collections, cloned and sent to the requesting module. If the data is in an array collection it is just cloned and sent back to the requesting module.
   
    The modules handle all this by passing a "call back function" to the parentApplication function, which is then stored in a "private var". This parentApplication private var never gets cleared so it is a reference to a public function in the module causing the module to not be GCed. Not the smartest code I ever wrote, (hindsight is 20/20) but it does make things run faster, until the memory leak wreaks havoc.
   
    I have started to rewrite this as a class which is instantiated in the module, but stores/reads its data in/from the parent application. I have tested it with a small live module (one query/combobox) and it seems to work. I am converting another 18 queries to test a much larger module, I will keep you posted, if you are interested.
   
    Paul R. Stearns
    Advanced Consulting Enterprises, Inc.
   
    15280 NW 79th Ct.
    Suite 250
    Miami Lakes, Fl 33016
   
    Voice: (305)623-0360 x107
    Fax: (305)623-4588
   
    ----------------------------------------
    From: Alex Harui <[hidden email]>
    Sent: 2/2/19 7:46 PM
    To: "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>
    Subject: Re: At least one memory leak problem is a custom combo box I use.
    Paul:
   
    I assume that means that your custom combobox is still causing a memory leak?
   
    IIRC, you have a test setup where you click a button to unload the module. Add another button that checks the number of children of systemManager.popupChildren.numChildren. That number should go up by one when the dropdown is accessed and go down by one after the module cleans up to try to unload. If it does go down by one, then the dropdown is probably going away and is not the problem. If it is there, then some code may still be accessing the dropdown property. Maybe override the dropdown property getter and trace who is accessing it.
   
    HTH,
    -Alex
   
    From: Paul Stearns
    Reply-To: "[hidden email]"
    Date: Saturday, February 2, 2019 at 3:22 PM
    To: Alex Harui , "[hidden email]"
    Subject: Re: At least one memory leak problem is a custom combo box I use.
   
    Alex:
   
    After I wrote my previous email, I changed the code to not access the dropdown. I was able to use "invalidateDisplayOptions," and use only the combobox items directly.
   
    I am still debugging.
   
    Paul R. Stearns
    Advanced Consulting Enterprises, Inc.
   
    15280 NW 79th Ct.
    Suite 250
    Miami Lakes, Fl 33016
   
    Voice: (305)623-0360 x107
    Fax: (305)623-4588
   
    ________________________________
    From: Alex Harui
    Sent: 2/2/19 6:09 PM
    To: "[hidden email]" , "[hidden email]"
    Subject: Re: At least one memory leak problem is a custom combo box I use.
    It is fine to access the dropDown property as long as it doesn't happen after other clean up code runs.
   
    It might be worth debugging to see if the dropDown is the actual problem. It could be something else, like some eventhandler that handles an event you dispatch from your code keeps a reference to the combobox. So use the debugger or profiler or other means to see if the dropdown is still on the display list. You can report on the children in SystemManager.popUpChildren. You can verify that the ComboBox's destroyDropdown is being called. And then try to verify that dropDown is not accessed after that.
   
    HTH,
    -Alex
   
    On 2/2/19, 1:43 PM, "Paul Stearns" wrote:
   
    Alex:
   
    Yes this code does reference the DropDown component. The code is there to handle finding items and moving the cursor to the appropriate item.
   
    For example if the data is;
   
    dog
    cat
    bird
   
    and c-a-t is typed it finds cat and highlights it.
   
    If the data provider changes and the values become;
   
    dog
    lizard
    cat
    bird
   
    the component will still keep cat highlighted.
   
    Given the above as a requirement, how can I clear make the component eligible for GC?
   
    Paul R. Stearns
    Advanced Consulting Enterprises, Inc.
   
    15280 NW 79th Ct.
    Suite 250
    Miami Lakes, Fl 33016
   
    Voice: (305)623-0360 x107
    Fax: (305)623-4588
   
    ----------------------------------------
    From: Alex Harui
    Sent: 2/2/19 1:55 AM
    To: "[hidden email]" , "[hidden email]"
    Subject: Re: At least one memory leak problem is a custom combo box I use.
    Hard to say for sure, but one thing to watch out for with ComboBox is running any code that accesses the dropdown property. ComboBox by itself should know how to destroy and unhook the dropdown, but if you run code that access dropDown after ComboBox thinks it cleaned up, then it will get stuck in memory again.
   
    HTH,
    -Alex
   
    On 2/1/19, 10:19 PM, "Paul Stearns" wrote:
   
    Alex:
   
    I have found that using a custom combo box I built causes the module that contains it to stay in memory.
   
    If I create a new instance but do not access it, everything is fine, As soon as I touch the dataprovider, it will not allow the parent module to unload (even if I set the dataProvider to null). I changed it to a standard combobox, and everything is ducky, but that doesn't have the features I need.
   
    If you could take a look at my ValidatedComboBox function and see if it is something obvious, I'd appreciate it.
   
    https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2FHyMTCC1Y&amp;data=02%7C01%7Caharui%40adobe.com%7C33aad47706c54824ba5508d6897674bd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636847539191479854&amp;sdata=QYVOWpwEK%2FHy9XqMiTqVtojoFF0YpyCRRcoe5Z5Vq70%3D&amp;reserved=0
   
    Paul R. Stearns
    Advanced Consulting Enterprises, Inc.
   
    15280 NW 79th Ct.
    Suite 250
    Miami Lakes, Fl 33016
   
    Voice: (305)623-0360 x107
    Fax: (305)623-4588
   
   
   

Reply | Threaded
Open this post in threaded view
|

Re: At least one memory leak problem is a custom combo box I use.

Paul Stearns
In reply to this post by Paul Stearns
Mick:

Thanks for the heads up. I just got it as it went to my spam filter.

I am not sure if the problem was the same, but once i stopped diddling with the sub component dropDown the problem went away.

I will keep this code in my back pocket, in case I need it.

----------------------------------------
From: Mick Powell <[hidden email]>
Sent: 2/2/19 10:07 AM
To: [hidden email]
Cc: "[hidden email]" <[hidden email]>
Subject: Re: At least one memory leak problem is a custom combo box I use.
Hello Paul,

I noticed a similar problem years ago in the flex 4.1 SDK, but it could have been there for a while before that. We used a pretty simple workaround that you could try: https://mickpowellstips.blogspot.com/2010/11/dropdownlist-memory-leak-flex-41.html. It might fix your issue, and I doubt it will do any harm to give it a whirl… There might be a better approach as well, but that was the way we solved it.

All the best,

Mick

> On Feb 2, 2019, at 12:55 AM, Alex Harui wrote:
>
> Hard to say for sure, but one thing to watch out for with ComboBox is running any code that accesses the dropdown property. ComboBox by itself should know how to destroy and unhook the dropdown, but if you run code that access dropDown after ComboBox thinks it cleaned up, then it will get stuck in memory again.
>
> HTH,
> -Alex
>
> On 2/1/19, 10:19 PM, "Paul Stearns" wrote:
>
> Alex:
>
> I have found that using a custom combo box I built causes the module that contains it to stay in memory.
>
> If I create a new instance but do not access it, everything is fine, As soon as I touch the dataprovider, it will not allow the parent module to unload (even if I set the dataProvider to null). I changed it to a standard combobox, and everything is ducky, but that doesn't have the features I need.
>
> If you could take a look at my ValidatedComboBox function and see if it is something obvious, I'd appreciate it.
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2FHyMTCC1Y&data=02%7C01%7Caharui%40adobe.com%7C231ee986cc774540946a08d688d65832%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636846851513368107&sdata=tT4%2BqA90aBbCdypmr59FIGnRgyJFN72d42fKr75dRE0%3D&reserved=0
>
> Paul R. Stearns
> Advanced Consulting Enterprises, Inc.
>
> 15280 NW 79th Ct.
> Suite 250
> Miami Lakes, Fl 33016
>
> Voice: (305)623-0360 x107
> Fax: (305)623-4588
>
>
>
>