Wine 3.2 - JScript memory leak

[fstenf]

I am converting a set of Windows applications over to run under Wine on an ARM processor and am having some serious memory leak issues with the JScript engine.

In a nutshell the application creates an instance of the JScript engine, calls ParseScriptText() with a piece of script code that is flagged as PERSISTENT when calling the method. Then we call the ParseScriptText() again with another piece of script that is dynamically created and finally we call SetScriptState(STARTED) to get the engine executing.

After each execution of the engine the application makes API calls back into the engine to get the state of variables that we set by the script code. After some short amount of time the system generates a new block of dynamic script code and calls the ParseScriptText() again with this code which immediately executes. Everything is working as expected and we can run and retrieve data back from the engine, however there is a rather aggressive memory leak that after some time chews up all available memory and the program is terminated.

I have ruled out the memory leak to be in my application code by instantiating the JScript engine and going thru the motions getting all the way to the point of executing the engine and there is no memory leak on the application side. I modified my application slightly to make both blocks of code Persistent and only call the ParseScriptText() once for each block and have them be resident in the engine to not keep parsing and building the code. With this I also modified some code in the JScript engine to allow me to just call the SetScriptState(STARTED) to execute the engine again without parsing/building any new code. This test also results in a memory leak. So, with that I believe the leak is in the execution side of the engine, not in the compiling portion.

Has anyone seen this or have any ideas as to where the leak may be? This portion of the application is critical to the application and with some attempted long term testing have seen that I can get the system to run out of memory within 12 hours if I push it to run the JScript code more frequently.

Any help or suggestions would be greatly appreciated.

Thank you,
David

[DarkShadow44]

Did you already try native jscript? If that helps, please file a bugreport, with a small sample program would be great.

[fstenf]

Unfortunately yes. My company is porting an old windows application that relies on native JScript to operate, that is what our customers write their operation instructions in, and then our application runs that code for a building automation system. I'll try to Tue when I'm back in the office to see if I can pair my application down to just include jscript engine calls with memory dumps.
Thank you for the reply.

[fstenf]

Sorry. I read that previous response incorrectly. I have not tried the native jscript and don't exactly know how I would go about changing my code to use it or how to use it. I am new to Wine and Linux in general. I am figuring things out pretty quickly but did not know that there was another JScript engine within Wine or Linux that I have access to.
Do you have examples or using the native jscript from within Wine?

I am working on creating a small sample app now.

Thanks.

[DarkShadow44]

"winetricks wsh57" should do the trick. That installs a few original windows dlls, including jscript.dll.

[fstenf]

"winetricks wsh57" should do the trick. That installs a few original windows dlls, including jscript.dll.

What do you mean by "original windows dlls?

I have the vbscript and jscript dlls in my Wine instance that are accessible by my C++ Windows application code currently which is where the memory leak is.

Is this a different version of the dll?

Thank you.

[DarkShadow44]

You see, wine reimplements windows dlls, these are the ones you're using by default. But then again, sometimes wine dlls are lacking. That's why you can use native dlls - aka the same dlls windows uses. That doesn't work for all dlls, but when it does, it usually works well.
If you're currently using the builtin dll (the wine dll) then trying the native is worth a try.

[fstenf]

That sounds great, I will give that a try. I have not played around much with Winetricks yet and was not familiar with the ability to bring in native dlls from windows. I am compiling for an ARM processor, are there any issues that I am going to run into? I have had to recompile all of my application for for the ARM processor to be able to run the application.

Again, thank you very much for your assistance to this point.

[DarkShadow44]

I'm sorry, I completely overlooked that ARM part. Native dlls are usually x86, so this approach won't work.

A minimal sample would be great for figuring this out though.

[fstenf]

I was afraid of that! Ok, I will continue with trying to create a sample application. I wanted to transplant some of our application code, but that will be very difficult. So trying to create new sample project.