Memory Leak?

default
{
    state_entry()
    {
        list mb=[NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY,NULL_KEY];
        mb=mb+mb+mb+mb+mb+mb+mb+mb+mb+mb+mb+mb;
        list eatupMemory1=[NULL_KEY,""];

        integer i=0;
        list mtest;
        integer j=0;
        for(i=0;i<8;i++) {
            for(j=0;j<10;j++) {
            mtest=mtest+[1,NULL_KEY, <1,1,1>, <1,1,1,1>, "asdf"];
        }
            mtest=[];
            llOwnerSay((string)llGetFreeMemory());
       }
                        
    }
}

output:

Object: 44
Object: 44
Object: 44
Object: 44
Object: 44
Object: Script run-time error
Object: Stack-Heap Collision

Since the memory gets released on each iteration, I'm unclear as to why there would be a stack heap collision. Other versions of this show a decline in free memory, however since free memory is buggy, I didn't quote those.

Because the LSL VM is indeed buggy; so much so that it appears any work on the LL VM has stopped long ago in favor of the Mono VM replacement which is well underway but (to my knowledge) has no expected release date associated with it.

i've always wondered exactly how it allocated the data into the memory space. It probably isn't a leak but a bug in the (de)allocation routines with regards to fragmentation. 16k of memory is so little the memory has to be handled intellegently. LL's design decision to only allow 16k of memory and not allow for pointers or a lower level LSL language was a lapse in judgement that we usualy expect Apple to make (no offense Apple).

The big advantage of Mono: script memory is allocated dynamicly, meaning 90% of scripts will use significantly less then 16k of memory. Sims *should* run faster because of this alone.

Yeh, if they were going to cram programs into 16k they should have based LSL on Forth.

variable handler
state default
: state_entry ( --- )
  0 handler ! "Bashi-bazouk" 1. 1. 1. <> 1. llSetText ;
: on_rez ( param --- )
  dup 0= if drop llResetScript else "" NULL_KEY "" llSetListenEvent handler ! then ;

INTERCAL!

hmmm does that mean recompiling every script in a sim might fight lag?

I *think* the VM, and perhaps also the compiler, don't handle scope very well, especially at the code block level. For instance, I wonder if this would work correctly if you put everything inside the for(i) in a separate function, and called that function from the (i) loop. In that case the memory would get allocated in a different function, and when that returns, it might clean it up better. Just a guess.

Intercal? For shame! Forth is a beautiful, lyrical language with an elegant structure and tremendous flexibility and versatility. Just because it doesn't look like "C" doesn't mean it should be compared with a joke language.

Sorry, I got to back Argent on this one. I would love to see a "lightweight" LSL along the lines of Forth. But then again I am biased, as I've been using Forth on-and-off both professionally (Sun' s OpenBoot) and personally (MUF on MUCKs) for a while now.

INTERCAL? Before my time, so no comment.

It would be nice if we could at least work with the VM directly by writing virt opcodes ourselves.

Don't get me wrong, not bashing the Linden's ability to write scripting engines. LSL is a compromise between Easy of Use and Small Tight Language. It's just...not very good at either.

*goes back to retrying to remember it's llStringLength and llGetListLength, or that it's llDeleteSubList and llListInsertList...*

My sincere apologies, no offense to forth intended; it used to be my favorite Sun boot-time driver hook language (and, coincidentally, the only one).

INTERCAL just plain amuses me.

Call it fragmentation or memory leak - it is still the same problem .. if we use the memory eventually we run out, even if we release everything.

Usually this is not a big problem when you have lots of memory free .. the fragmentation leak is slow enough you can manage it except with periodical resets .. which complicate the user experience too much.

I guess we can't really except a fix for this, however, with mono around the corner.

The solution in situations such as these (when there are bugs in underlying memory models) is to write a memory pool and handle all deallocation/allocation ourselves.

Unfortunately, because we can't even allocate our own memory pools, I'm not sure this is possible.

LL, this is a deal breaker. Please fix!

This is something that will probably be addressed durring the lsl backend conversion to mono byte code. So I'd say they are working on it.

as a newbie (well hopefully I'm little beyond this stage now) am I making a mistake ramping up on LSL right now? i.e. I see mention of this "mono" upgrade? Anyone got links to some info on this "mono" upgrade? It isn't the C# version of LSL is it? (I thought someone mentioned this at one stage in a thread)

Mono is essentially an open source version of the .net framework. I think that a C# program will run on a machine using the mono framework

However, the upgrade to mono does not mean the LSL will change at all, at least not at first.

Mono and .net compilers both compile code into a bytecode, which is more efficient than the what LSL currently compiles into. That's the main part of the upgrade. To a scripter, it will not look much or at all different. It will run much faster and take fewer server resources.

So no, ramping up lsl is not a mistake. In the future, the conversion to mono may allow for more datatypes, more functions, pass by reference, faster timers and possibly even object orientation or the ability to write scripts in a mono/.net language of your choosing, but that will all happen slowly and you'll be ahead of the game if you already understand LSL.

Babbage Linden has posted about the mono conversion on his blog, here