[wing.t.lee]

If you see a global variable with value = null, that object has been successfully destroy()d and will be garbage (unless your code holds onto another reference to it, as with any object).

Per further check and continue using, I still find "null value" global variables accumulated including isc_ValuesManager, isc_ResultSet, isc_TextItem, .... and the memory usage is still going up.

As mentioned in quote that it is possible the variable is "holds onto another reference to it, as with any object". How can I check it out in Development Console?

[Isomorphic]

Again, the presence of these null references does not indicate a leak. The fact that those variables are null means the objects are no longer referenced from global scope, which is a good thing, because it means they can be garbage collected.

The Developer Console cannot tell you if you have a bug in your code where you are still holding on to some other reference to these widgets, which would cause a leak. For this, you need to use standard debugging techniques. You haven't shared runnable code with us, so at the moment, we can't help with this.

instead of worrying further about those null variables, please take the steps we've been recommending:

1. Tell us whether the ResultSets you see in the "window" object that are non-null have "cacheAllData" in their toString() result

2. Retest for a leak with the new build, again testing for memory exhaustion, not just memory increase (memory increase means nothing at all unless you can show memory exhaustion)

[wing.t.lee]

Hi

I try to repeat a function for over 200 times and I find that from FireBug DOM tab

1. the object with content is keep the same without out accumulate
2. but for those object with null content (should be destroy as mentioned in the previous post) is accumulated, for example there are over 2000 TextItem, and 200 ValuesManager objects (although all content null)
3. And I find the performance of this same function is significant degrade from 2-3 seconds to 8-10 seconds when 200 times.
4. From Task Manager that memory usage of Firefox.exe grow from 250M to 720M
5. per attached image and we find the about:memory it grow from 29M to 166M, and I also find 40M detached. Nearly no memory release after clicking the GC button (see images for screen cap of about:memory after 200 times ...)

I guess the slow response (point 3) would be caused by the accumulated null isc_ objects. So I want to know any method I can identify the null object and clean it? How can I prevent the accumulate null isc_ object?

[wing.t.lee]

Dear support,

I have repeat the same test "to repeat a function with open tab and close tab" and now we use the SmartGWT Showcase public site, in firefox 24.3.0 and loop for over 10000 times.

http://www.smartclient.com/smartgwt/...abs_add_remove


I get find the following
1. I find over 10000 null content isc_Tab_XXXX objects accumulated without clean (see attached image)
2. in Task Manager, I find firefox.exe growth from ~250M to 705M without any memory release
3. about memory grow to 147M for smartgwt showcase, and I also find some detached memory from smartgwt ~18M

Which get the same sympton as my application. The main different is my memory usage inside the Tab is larger, so I meet the slow response on my application in quicker time...

So we want to ask is the memory leakage or object leakage caused by SmartGWT framework? Is there any patch in SmartGWT that can fix this?

[Isomorphic]

This is assigned to a developer for investigation. We'll update when we have more information for you.

Regards
Isomorphic Software

[Isomorphic]

We've made a couple of minor framework changes:
- we are now re-using IDs for automatically created components. In other words once an automatically generated Tab with ID "isc_Tab_5" (for example) is destroyed, the ID will be re-used and applied to a new tab. This will prevent us from creating thousands of null slots in the case where you saw this.
- we also are deleting the variable names from destroyed widgets rather than simply setting them to null, where this is possible (this is not supported in all browsers - for example Internet Explorer 8 throws an error if you attempt this).

In our testing this gets rid of the problem you're describing in the Add / Remove tabs sample. We are no longer seeing a small slow memory leak in this sample.
You can pick up the next nightly build to test this (dated Feb 14 or above).

This may resolve the issues you're seeing in your application as well, but if, in a real world usage, you're seeing significant memory leakage, it still seems quite likely that some more significant objects are being retained in memory than just the ID strings.
We'd recommend you re test with the new SmartClient / SmartGWT libraries tomorrow regardless. If the problem persists, this may still be an application level issue (not allowing some local references to created objects to go out of scope), or possibly a framework issue, but to comment further we'll need more information.

One aside - if you haven't already, we'd recommend you do perform a real-world test with firebug not running to see if the memory is growing incrementally without ever being reclaimed in a "real world setup".
To exit firebug, you need to close firebug, then close, then reopen firefox -- firebug is not fully closed unless you restart the browser)

Regards
Isomorphic Software

[wing.t.lee]

Thx Isomorphic admin

- I'm using SmartGWT SmartClient Version: v9.1p_2014-03-04/PowerEdition Deployment (built 2014-03-04) version, I want to double confrim your fix is on 4.1p Power Edition?

- other than isc_Tab_XXX, I can see other such object with null value after destroy such as isc_ComboBoxItem, isc_DateItem, isc_DoubleItem, isc_HeaderControl, isc_ListGrid, isc_ResultSet, isc_SectionHeader, isc_SectionStack, isc_StaticTextItem, isc_TextAreaItem, isc_TextItem, isc_VLayout. Is the new fix also effective for those component....

- As my application is already in Production and on version "v9.1p_2014-03-04/PowerEdition Deployment (built 2014-03-04)", I want to know can I have some quick fix by removing those isc_ objects based on the old version? (we don't need to perform the regression test in short time due to SmartGWT version upgrade... So if we can remove in destroy method as a quick fix, do you have sample code? do we need some native method?

[Isomorphic]

Yes, the change was applied to 4.1. Yes, it would affect all objects that have automatically assigned global IDs.

As we keep repeating over and over again: if you are experiencing significant memory leakage, these ID/null pairs you are seeing in global scope are not the problem.

It would take something like weeks of continuous usage of an application without ever reloading the page before this very very slow leak would ever add up to a significant amount of memory.

So if you are seeing a significant memory leak in your application, something that is actually affecting your end users, you should investigate that leak and stop worrying about these ID/null pairs.

[wing.t.lee]

Yes, the change was applied to 4.1. Yes, it would affect all objects that have automatically assigned global IDs.

As we keep repeating over and over again: if you are experiencing significant memory leakage, these ID/null pairs you are seeing in global scope are not the problem.

It would take something like weeks of continuous usage of an application without ever reloading the page before this very very slow leak would ever add up to a significant amount of memory.

So if you are seeing a significant memory leak in your application, something that is actually affecting your end users, you should investigate that leak and stop worrying about these ID/null pairs.

Per testing the latest SmartGWT Public ShowCase again and I find that the object leakage is not found

Same step that I test the following link and add a new Tab and Close the new Tab, and I repeatly perform this action for 4 hrs and more than 10000 times on same session.

http://www.smartclient.com/smartgwt/...abs_add_remove

I still find memory leakage and slow response of this action

- Response from extreme fast (less than 0.3s) to slow > 1.2s after 4 hrs repeat work. Experience Slow Response after 4 hrs
- Task Manager FireFox from ~200M to 580M
- about:memory for that URL from <100M to >250M


Question 1:
So if for SmartGWT ShowCase case, how can I check the memory hold up by which object and any program fix need?

Question 2:
Is there any wiki or FAQ explicit list out how to code the SmartGWT application in order to prevent client side memory and object leakage?

Question 3:
As mentioned before, my application is developed and tested on v9.1p_2014-03-04/PowerEdition Deployment (built 2014-03-04) version. You fix is on built 2015-02-14. Can you advice where can I find the list of bugfix or minor enhancement between the two builds 2014-03-04 to 2015-02-14?

[Isomorphic]

10,000 repeats of creating and destroying a set of widgets is unlikely to occur in a real application except over a timeframe of multiple weeks of continuous usage. Even if we could reproduce a slowdown, this would not qualify as a bug, so we will not be attempting to reproduce the slowdown; however, as we have previously noted, the slowdown is likely to be caused by Firebug being active rather than any actual problem with SmartGWT.

1. You should use standard debugging techniques, which are generally the same in any programming language and environment, to find leaks. If you need training in order to do this, or you would like Isomorphic to perform the debugging on your behalf, both are available as commercial services from Isomorphic. However, because you have not identified a bug in SmartGWT, or even shown that there is likely to be one, this is not a service that will be performed by Support; you must purchase it separately

2. We have already explained in this thread that the basic advice for avoiding memory leaks is in the QuickStart Guide, and we have explained in more detail in this thread. Nothing further is needed here.

3. There is no list of patches available to review, but there is no point in reviewing one either. We do not provide patches as separate downloads because we cannot test all possible combinations of patches, so you need to download the latest build in order to get the patch that avoids extra nulls in global scope. Once again, the patch resolves an extremely slow, very minor memory leak that would not have any effect on real world usage by end users, so you don't actually need it anyway.

We have covered all of the above points multiple times with you - if you need further help on this point here are your two options:

1. submit a standalone, ready-to-run test case that shows a memory leak that would actually affect typical end users, and is clearly a framework bug

OR

2. purchase Consulting services from Isomorphic, so we can review your application code and identify the source of the leak (which may be a bug in your code)

[wing.t.lee]

10,000 repeats of creating and destroying a set of widgets is unlikely to occur in a real application except over a timeframe of multiple weeks of continuous usage. Even if we could reproduce a slowdown, this would not qualify as a bug, so we will not be attempting to reproduce the slowdown; however, as we have previously noted, the slowdown is likely to be caused by Firebug being active rather than any actual problem with SmartGWT.

We have review the test case as mentioned about and we have choose a more realistic case in SmartGWT ShowCase

My case in my application
our data input operator will update the order (transaction) that have over 300 fields on the screen (including text field, combobox) and the entity is 3 levels. And they need to complete the 80-100 records within 1 hour for every 9AM to 10AM. And it including search data to ListGrid and double click to show 300+ fields entity, and click update to send back the data to server side.


We find the similar example in SmartGWT ShowCase
URL: http://www.smartclient.com/smartgwt/showcase/?sc_selenium=true#featured_complete_app

Test Case: loop 100 times and repeatly update records on the Description Field with new value (only 8 fields in the Form of ShowCase).

Before 100 submit, we find task manager usage 209M and About:Memory usage 26.75MB (after open the SmartGWT ShowCase Featured Complete App and Searched "Category" = "Office Paper Products")
(see attached images: about_memory_init.jpg, task_manager_init_jpg)

After 100 Submit, we find task manager usage grow to 237M and About:Memory grow to 46.62MB (even after click "GC" button for many time in about memory) (see attached images: about_memory_after_execution.jpg, task_manager_after_execution_jpg, screen_after_execution.jpg)

Since there is only 8 fields on the sample app from SmartGWT ShowCase Screen, but for My App that it including over 300 fields data, so the memory leakage is very serious (and after 15-20 submit the memory grow over 300M and response time is significantly impacted to over 10s).

Luckily it would not be too significant performance degrade if we test ShowCase, but if we apply the same coding on a case of a form that have 300 fields and 3 levels entity, it would cause big impact.
It would be more efficent if we check this issue based on SmartGWT ShowCase code as we can reproduce case of memory not release, as well you have much experience on the code detail of SmartGWT ShowCase...
So can your check why SmartGWT ShowCase will have significant grow on memory (by 20M for my test)? How can I fix this in SmartGWT ShowCase?

[Isomorphic]

Once again, memory increases are not evidence of a leak; only memory exhaustion shows a leak.

Please make a note of this as we have also repeated this several times.

There is nothing to investigate or fix here, so we are still waiting for you to take the steps described in our previous post.

[wing.t.lee]

Once again, memory increases are not evidence of a leak; only memory exhaustion shows a leak.

Please make a note of this as we have also repeated this several times.

There is nothing to investigate or fix here, so we are still waiting for you to take the steps described in our previous post.

1. You should use standard debugging techniques, which are generally the same in any programming language and environment, to find leaks. If you need training in order to do this, or you would like Isomorphic to perform the debugging on your behalf, both are available as commercial services from Isomorphic. However, because you have not identified a bug in SmartGWT, or even shown that there is likely to be one, this is not a service that will be performed by Support; you must purchase it separately

It's not related to debugging techniques issue but we concerning on why there is memory un-released after we submit form in SmartGWT ShowCase, so I will try to prove this in SmartGWT Showcase by loop the action until the memory exhaustion. Will update you the result. If no memory leakage issue, I think that it would release and cannot reach the memory exhaustion.
(FYI that we already experience on memory exhaustion case for the open/close Tab case... but you just treat this as invalid. but if really no memory leakage, why I feel slow perform and memory growth,...)

(If we prove that the case is SmartGWT framework memory leakage issue, it should not be a commercial service, we also suggest isomorphics can perform such test to make sure no memory issue...)

[wing.t.lee]

As mentioned we have test the form submit until a very high memory usage already (from 200M at initial, to 1G after 3 hours usage)

And the response time and memory usage is as following

Initial (just open the SmartGWT Showcase Featured Complete Application)
- Response Time: 1.8 seconds for 6 form submissions
- Task Manager: 175M
- about memory: 27.66M (for ShowCase usage)

one hour later
- Response Time: 3.2 seconds for 6 form submission
- Worst case: response time 1-1.2 seconds for one submit, possibly GC in Firefox
- Task Manager: 550M

two hour later
- Response Time: 3.5 seconds for 6 form submission
- Worst case: response time 1.5-1.8 seconds for one submit, possibly GC in Firefox
- Task Manager: 785M

three hour later
- Response Time: 4.2 seconds for 6 form submission
- Worst case: response time 3 seconds for one submit, possibly GC in Firefox
- Task Manager: over 1G
- about memory: 504.64M (for ShowCase usage)

From result, we get the following finding:
"the response time is continuously degrade (from 1.8s to 4.2s) and main usage of memory for firefox is in SmartGWT ShowCase grow continuously grow (from 175M to 1G for Task Manager and 27.66M to 504.64M for about:memory)"

Can you help to check the SmartGWT framework for the memory leakage?

[Isomorphic]

We have explained this before, but to cover it again: browsers have various strategies for when exactly they will reclaim memory. In some cases, they will reclaim memory of certain kinds only if the operating system refuses to allocate more memory; the browser will not necessarily attempt to release memory even if performance is somewhat degraded.

So again: memory exhaustion proves a memory leak, nothing else does.

As far as your reported testing times of "three hours later" - are you actually torturing human beings by making them repeatedly press buttons in a sample application thousand of times? Please do not do this. Simply create a loop that repeatedly performs the same action that the button click performs.

As far as reporting any results you may have, report the number of trials, not the time taken to do them. Whether you have automated the repetition of the trials or not, a very high number of repetitions would indicate an extremely slow leak that will never affect real end users, and problems that are merely theoretical and do not affect end users do not qualify as bugs.

Finally, we have repeatedly pointed out:

1. you need to point out what version you are testing, every time. If you are still testing the online Showcase, since the online Showcase has not been updated with the fix for the very slow leak you previously reported, all such efforts are useless.

2. you must not have Firebug active while doing leak tests. You need to in fact disable the Firebug extension and then restart the browser before beginning any leak testing. If you have not been disabling Firebug before doing testing, all of your results are useless; if you have been disabling Firebug before doing testing, you need to explicitly say so.

In sum, we are trying to fix whatever problem is actually affecting your end users. By repeatedly ignoring our advice and focusing on problems that would never affect your end users, you are slowing down the troubleshooting process to the maximum extent (and quite possibly torturing your testing team at the same time :)