LSL Errors

Run-time error messages

A script may stop running, and chat at you the complaint "Script run-time error", followed by another complaint such as:

Script run-time error: Heap Error

Don't be evil. For example, don't return a list of one entry that is the result of a routine that returns no result.

Script run-time error: Lists may not contain lists

Don't try adding a list into a list.

Script run-time error: Math Error

Float divided by zero, integer divided by zero, etc.

Script run-time error: Stack-Heap Collision

The Stack has collided with the Bytecode or the Heap.

Each script runs inside 16 KiB of memory divided out among Bytecode, Stack, and Heap.

You can cause collision by compiling too much script, which produces too much Bytecode. The script compiles and saves successfully, but when you rez an object containing the script, the script crashes, immediately or while running.

See llGetFreeMemory.

Example Scripts

Compile and run examples like these to experience the script run-time errors.

default
{
    state_entry()
    {
        llOwnerSay((string) [llOwnerSay("bye")]); // Script run-time error: Heap Error
    }
}

default
{
    state_entry()
    {
        list once = [];
        list twice = [once, once]; // Script run-time error: Lists may not contain lists
    }
}

default
{
    state_entry()
    {
        float one = 1.0;
        float zero = 0.0;
        float quotient = one / zero; // Script run-time error: Math Error
        llOwnerSay((string) quotient);
    }
}

default
{
    state_entry()
    {
        list entries = [0];
        while (TRUE)
        {
            entries += entries; // Script run-time error: Stack-Heap Collision
            llOwnerSay((string) llGetListLength(entries));
        }
    }
}

Compile-time error messages

The SL GUI may reject some code that you feel is perfectly clear, printing ERROR at you and then explaining with some further complaint.

ERROR: Type mismatch

You must name the .x .y .z .s components of a vector or rotation that you're assigning, you can't assign them all at once from a list, for instance:

default
{
    state_entry()
    {
        vector vec = (vector) [1, 2, 3]; // ERROR : Type mismatch
        llOwnerSay((string) vec);
    }
}

ERROR : Byte code assembly failed -- out of memory

You must make each script reasonably small.

For example, the compiler says you typed too much script if you cascade too many else-if's:

demoElseIfCompileError(integer count)
{
    if (count == 0)
    {
        ;
    }
    else if (count == 1)
    {
        ;
    }
    else if (count == 2)
    {
        ;
    }
    ...
    else if (count == ...)
    {
        ;
    }
}

How much script is too much script can vary astonishingly. For example, the 2007-08 Second Life clients varied as much as 30X, from one to the next. Specifically, the Windows client accepted 22 else-if's and refused 23 else-if's, while Mac OS X was accepting 692 else-if's and refusing 693 else-if's.

Compilation limits that vary by operating system in effect work as a copy-restriction mechanism. Any resident can run the script compiled by the less limited compiler, but residents who have only the more limited compiler cannot save changes to the source.

See llGetFreeMemory, llMessageLinked.

ERROR: Syntax error

You must punctuate the script and spell the words of the script as will please the compiler, of course.

Also you must make each script reasonably small. The compiler may astonishingly complain of a "syntax" error rather than politely complaining more specifically of an "out of memory" "byte code assembly failed" error.

For example, the 2007-08 Windows Second Life client complained of a Syntax error if you cascaded too many else-if's. The exact limits enforced can vary astonishingly. For example, the 2007-08 Windows Second Life client sometimes accepted as many as 22 cascaded else-if's, but also sometimes rejected as few as 19 cascaded else-if's, depending on other details of the script.

Compilation limits that vary complexly by context in effect discourage development of scripts on one operating system for use on another operating system, since a script that runs on one operating system may actually fail to compile on another.