Win 8.1 + IE11 - Possible memory leak

[ueng]

---

SmartClient version: SmartClient_v91p_2015-11-17_LGPL
OS: Windows 8.1
Browser: MSIE 11

In our tests, we set up a clean VM as follow:
Pagination: off
RAM memory: 2048MB
Windows: 8.1
Core: 2
VM provided by Microsoft at: https://dev.windows.com/en-us/microsoft-edge/tools/vms/

---

Our application needs to stay open for at least 8h without the need to close and open the browser again.

Currently, we need to close and re-open the browser every 3h or less.

We load the code in the browser as a usual user (without any developer tool). And leave the VM open. After some time, the OS will ask to close MSIE due to low memory. If we keep with the test running the OS logs

We did several rounds and at the average with this code we have a leak around 2.7 MB per minute

The code below is a code similar to what we have and is the one used in our tests:
http://pastebin.com/neBsHrtU

Can you guys please check for any memory leak in this scenario?

[Isomorphic]

Hi,
We have a good starting point overview about memory leaks
here, which discusses common ways memory leaks can develop in application code. This includes
- "orphaning" objects - SmartClient widgets, data objects, etc by creating them, and failing to clear them up (for widgets this would mean calling 'destroy()' and ensuring any local references to the widget are released)
- using certain tools, like having the "track RPCs" checkbox checked on the developer console (this may be set even while the developer console window is not visible - the setting is remembered in cookies and reset automatically when you reload the page)

It also discusses how memory will grow and shrink during time and this doesn't indicate a leak in itself. However the fact you're seeing the browser crash with out-of-memory errors obviously implies there's a real leak here!

One other thing worth mentioning - IE has an issue when evaluating JS code (or JSON) that it can cause memory to leak. This is discussed here. This should not be an issue if you are using either the SmartClient server, or you have useStrictJSON set to true on your dataSources.

If none of the above information helps identify what's going on in your usage we will take a look at your test case. Before we do - can we clarify that this test case actually demonstrates the problem -- if you leave it running for a significant number of hours it will exhaust the browser memory? We just ask as you describe it as being similar to the code with which you are encountering the problem, so we want to clarify that you actually see this behavior running this specific test case.

Thanks
Isomorphic Software

[ueng]

Hi there,

First thanks for your answer!

Regarding your questions:

1) The code is close to what we have in our end.
2) The code published on pastbin is quite simple and only use SmartClient libs no other vendors
3) The windows start to complain about the IE using too much memory and after wait more the browser becomes unresponsive
4) Some other test using VM, the whole VM restarts due to lack of memory

Please check the posted code.

Thanks again for the attention and looks forward to an answer.

[ueng]

Hi folks,

Any news on this post? Do you need any additional info from us?

Thanks in advance

[Isomorphic]

The news is not good. There is no leak in Chrome or Firefox, indicating that this is not an actual coding error where SmartClient is holding onto objects, but some kind of memory leak bug in IE11 (AGAIN - this has happened with every release, basically - different memory leak bugs each time).

Coding errors are easy to correct, native leak bugs can be spectacularly hard to find and work around. This could take a long time to resolve.

We recommend that, if you have the ability to do so, you tell your users that for all-day or multi-day sessions, they must use a browser other than IE. This is what we recommend anyway, and most organizations have already heard this from multiple vendors.

[ueng]

Hi there,

Thanks again for your attention but we are already doing this recommendation to use Chrome and FF.

We have some big customers that cannot use other browsers due to internal policy (Government, Military, etc...)

How long shall we expect a fix from the Smart-Client side?

Thanks in advance

[Isomorphic]

Sorry, on this kind of bug, there's no reasonable way to give an ETA. It's like "basic research" in science.

We also cannot tell you for sure that the leak can be entirely corrected. With IE9 for example, there is a slow leak that cannot be fully corrected while delivering the functionality you're using.

[ueng]

Hi there,

Our focus is mainly on IE11, but please keep us posted with the evolution on this area.

[Ozi]

Hi all,
it seems, we have kind of similar problem with the leaking memory on the IE11 browser (long time running application in IE causes it's crash or reloads the page due to not enough memory...).
I can imagine there is a real memory leak problem in the IE, but I found something interesting in the memory profiler of the IE and would like to ask for your opinion.

In my example, there is an application with one ListGrid, which periodically reloads the data per 10 seconds - we call listGrid.invalidateCache() to invoke fetch, nothing complicated. Otherwise the application was not touched.
After one hour, the used memory was increased by 60MB.
The compare of the memory profiler snaphosts shows, there is a little increase of the used memory with each fetch request (please see the attached screenshot).
The only changed object marked by profiler was the "changed()" function of the RPCManager transaction (see RPCManager._createTransaction.transaction.changed). This function controls, whether to push the RPC update - guess to log to the dev. console - even if it is not currently displayed.
So I tried to switch off the RPC requests loging in the console and the memory increasing was much much lower....

I'd like to ask if this is a correct behavior? Do you think, this might be a problem connected with the memory leaking on the IE11 browser?

[Isomorphic]

If you have the "Track RPCs" feature enabled, memory will grow with each RPC transaction regardless of whether the Developer Console is currently open, regardless of browser. This is because the RPC requests have to be tracked so that they can be shown when you *do* open the Developer Console.

This and other false memory leaks are covered in the Memory Leaks overview in the docs.

[Ozi]

Thanks for the response. I got the point.
Am I correct that the default value for the trackRPC property is "unChecked"?
Is it possible to somehow set/force this property in the code? Just to be sure, the memory problems at our users have nothing to do with this tracking feature...

And one more idea - with the tracking RPCs enabled - would it be possible to somehow limit the number of remembered/loged requests? We checked our usecase to run over night (one still refreshing listGrid), tracking RPCs enabled, Dev. concole closed - the memory raised to 1,5GB. This would be quite dangerous, in case someone let the tracking enabled and closes the console and forgot it :)

[Isomorphic]

The default for Track RPCs is unchecked and there is no documented way to turn it on programmatically - you would have to, for example, reverse engineer the cookie format used by the Developer Console.

No, there's no way to limit the maximum number of RPCs being tracked. Like most developer tools, it assumes you really mean that you want to track things, and will eventually run out of memory. It's quite a stretch to call this "dangerous" when the consequence is just that a browser tab crashes.

[Isomorphic]

We have been investigating this issue in the background for some time and have found, and fixed a leak that actually occurs in all browsers, but in browsers with modern JavaScript engines (eg Chrome, Firefox), the leak was negligible: an application could run continuously for months on end, and even a test case specifically designed to show the leak would take weeks to run out of memory.
This same leak was not negligible in IE and could cause it to exhaust all system memory in a few hours.

Anyway - we believe this issue should be fixed for you now. The fix should be present in the current nightly build (Jan 6) on the 9.1 branch and all more recent branches.

Regards
Isomorphic Software

[ueng]

We'll upgrade to last 9.1 version and check again, keep you posted.

[ueng]

Looks like the new version reduced about 5x the leak on iE11 - thank you!

Now I'll move my memory leak hunting to iE11 + iFrames, to address it I'll open a new post with the same pieces of evidence/src/environment.