Escript memory leak

[Bracco]

i think this has always been there, and maybe reported a long time ago, btw

there is some kind of memory leak under some circumstances, in escript scripts. i can't exactly tell why, however its easy to reproduce and here's a link to a sample pkg that reproduces it http://dragonslight.altervista.org/ctrlleaktest.rar (download with right click->save object as)

just compile the pkg and use .leak to test it.

here you can see the allocated memory before use



and here after the script has run:



as you can see i am using the windows build, 97 2007-01-04 RC2. this however, happens also on 95 and 96 (probably been there since the beginning)

i also made a very stupid C++ program with similar behaviour just to make sure it isn't a bad memory management from windows, but it isn't

i don't know if this leak is fixable or not, however, why not compile POL with a garbage collection library? and make a function like uo::CollectGarbage that cleans the memory (like runuo does) ?

[Bracco]

for some reason i can't post the C++ source of test program, but i think that's pretty useless

[Barbeirosa]

RunUO is run within the context of the .NET Common Language Runtime, which is what provides the garbage collection. It is built into the very low-levels of the .NET Framework itself. It's not something RunUO is providing at all. Not only that, the RunUO folks are violating a fairly standard, well-known 'rule' that you do not run explicit garbage collections in server programs ever; if you need to, something's wrong with the program itself. (given how 'scripters' can extend RunUO, it should be mentioned that it's probably very likely that many badly written classes will, in fact, seem to 'need' explicit garbage collection, so I guess I understand it from that point of view)

Point of this post: POL cannot simply "add garbage collection".

[Bracco]

i know garbage collection is an intrinisc characteristic of C# and Java.
POL is written in C++, there are some libraries that provides various implementations of grabage collection.

btw, as i said, would be better to have all leaks fixed

[Bracco]

i did a bit more searching in the forum and found this in the 097 Coregina Roadmap :

Remove known Memory Leaks (cfg and ecl-file handling).

i knew about cfg leaks (infact i don't use appendcfg* functions nor unloadcfg in my scripts) but not the other, to me it seems related to what i am reporting...

is there a workaround for that leak?

the thing is getting out of control, ram usage ramps up extremely fast

[MuadDib]

Link to rar no longer works

[Bracco]

it does, just right click -> save object as

[MuadDib]

Hrm, says it isn't a valid rar file

[Bracco]

weird, try this one

http://www.sharebigfile.com/file/127677 ... t-rar.html

however its a simple textcommand that starts another scripts with a heavy cycle that does nothing but adding useless trash to an array.

[MuadDib]

Does appear to be start_script() related. You do the looping inside main script and it's fine.

In the started script, if you empty the garbage var, it's fine, before exiting the script.

[MuadDib]

If i reset your array to 0, and use .leak 100, there is usually still around 2mb leak it appears. Can you verify this also? And verify if it only happens in start_script for you, or if in the main cmd script also?

[Bracco]

in my experience, its not a start_script issue but more a "how-many-instances-of-the-script" issue...

the more instances of the same script are running together, the more it leaks.