Pascal script memory management

[david_navigator 12]

One of my apps uses PascalScript to allow the user to customise various tasks. However as I've recently discovered it's really easy for the end user to write a script that leaks loads of memory. 

As far as I can see PascalScript doesn't do any kind of memory tidy up when the script ends - it expects the script's author to do that.

Is there some way to encapsulate the instantiated TPSScript object in such a way that I can free any memory when the script object is freed ?

 

Something like (in psuedo code)

Create memory container;
PSScript:=TPSScript.Create(nil);
PSScript.Script.Assign(fScript);
PSScript.Compile;
PSScript.Execute;
PSScript.Free;
Destroy memory container;

 

 

[Lajos Juhász 293]

You cannot do achieve that in safe manner. For example:

 

var

  t: TStringList;

 

begin

  t:=TstringList.create;

  t.Free;

end;

 

How you are going to know if t is freed or not?

[david_navigator 12]

4 hours ago, Lajos Juhász said:

How you are going to know if t is freed or not?

I was hoping there was something that the OS could deal with. 
If I made the scripting engine a stand alone EXE then whatever the user wrote, Windows would clean up when the exe closed. I was hoping that there might be some way to achieve that within my app.

Doing some research I see that Job Objects details "The virtual memory of job objects isolates the memory behavior of a group of processes (tasks) from the rest of the system", but so far little about how this is achieved.

[Kas Ob. 121]

2 hours ago, david_navigator said:

If I made the scripting engine a stand alone EXE then whatever the user wrote, Windows would clean up when the exe closed.

Yes, this is the only way, also you can make it a DLL, only make sure to not use a shared memory memory manager with the exe.

 

Use the OS heap API as local memory manager.

[david_navigator 12]

On 3/22/2024 at 8:13 PM, Kas Ob. said:

Yes, this is the only way, also you can make it a DLL, only make sure to not use a shared memory memory manager with the exe.

 

Use the OS heap API as local memory manager.

@Kas Ob. could you explain in a little more detail about the memory manager please ? 
 

[Cristian Peța 103]

On 3/22/2024 at 7:22 PM, david_navigator said:

I was hoping there was something that the OS could deal with.

 

29 minutes ago, david_navigator said:

@Kas Ob. could you explain in a little more detail about the memory manager please ? 

The OS will free the memory when you unload the dll.

[david_navigator 12]

16 minutes ago, Cristian Peța said:

 

The OS will free the memory when you unload the dll.

Thanks, but I meant "only make sure to not use a shared memory memory manager with the exe."

[Cristian Peța 103]

Simply don't share dll memory with the exe.

https://docwiki.embarcadero.com/RADStudio/Sydney/en/Sharing_Memory

[Kas Ob. 121]

2 hours ago, david_navigator said:

@Kas Ob. could you explain in a little more detail about the memory manager please ? 

Have a look at this HeapMM 

https://github.com/maximmasiutin/FastCodeBenchmark/blob/master/MMv1_BV113/HeapMM.pas

 

This is more than sufficient for your need case, only you must understand that the way you will use the DLL is similar to the way you intended to use the separated process,

in other words : be careful ! there is no memory sharing for managed types !

So no string or arrays passing (among other managed types) between your exe and that dll !

 

Last thing, there is this directive in that HeapMM

{$DEFINE USE_PROCESS_HEAP}
This should be disabled
{.$DEFINE USE_PROCESS_HEAP}

By disabling it, the dll will be using its own heap and will free it so if it does leaks memory it will be erased on unloading the library.

 

Also note this: if you are going to run multiple scripts concurrently then this will the DLL approach will be challenging, so either let them run and every now and then unload the library (FreeLibrary), or you can copy the DLL with different names and loading them separately, just food for thoughts.

 

ps: understanding how memory manager works is nice to know, the the heap one is the most minimalistic form for a memory manager.