Feature Proposal: Script Error handling and recovery

I recently entered a proposal that scripters may want to jump on:



Vote here: http://secondlife.com/vote/get_feature.php?get_id=188

This is one feature proposal we shouldn't let sit around any longer. Having a way to capture script errors is so important to any programming language, even more so when dealing with production level products.

It seems a logical extension of the language to allow a script_error event that passes in the error message as an argument. The LSL internals clearly have this somewhere, in order to display the message in the script error box and the little icon.
This event should leave all of the internal error handling in place and just notify the script that there was an error, such that it can handle itself.

Please, check out the proposal and lets vote it into the language.

Yeah, wouldn't it be great?!? Unfortunately there was a proposal over a year ago by Lex Neva that seemed to slip through the cracks.

You can find the proposal at http://secondlife.com/vote/index.php?get_id=188, please give it a few votes.

just voted - thanks

(whilst this is very important and seemingly simple from the requirements perspective, I wonder if this is one of those that may be very difficult for them to implement due to design/architecture - would be nice for LL to let us view their internal development comments against the proposals)

Forum cross posting, not cool.

Moving (from script tips to feature suggestions) and merging.

I like the idea of having the event. Surely though we could extend this slightly and simply have a script not break entirely in the first place? ie in the event of a stack-heap collision the script will simply dump all of its variables and switch over to the script_error() event with a number identifying the error type.

If no such event exists in the code then it will give the error as normal, otherwise it will trust the event to do that.

Stack-heap collisions should surely be detectable before-hand anyway? ie if we are at the end of the stack and we try to add a new variable, extend a list or so-on, then we simply can't so throw away all variables.

The script_error() event would probably have to be limited in what it can do, if it flushes variables then there's no way of reporting what caused the error, only what went wrong (but that's the case already anyway). All you really need in the script is the ability to reset, or give a message. Resetting probably shouldn't be mandatory though, as there are scripts which after resetting will just break again anyway.

There are security issues in having a trap handled by another script... how about this?

In the script:

default
{
  state_entry()
  {
    llDebugScriptPin(19842001);
    //..
  }
  //..
}
//..

Then, in another script in the same prim:

default
{
  state_entry()
  {
    llDebugPinnedScripts(19842001);
  }
  debug_trap(integer n)
  {
    integer i;
    for(i = 0; i < n; i++)
    {
      string reason = llDebugReason(i);
      llOwnerSay("Trapped "+llDebugName(i)+": "+reason);
      list stack = llDebugCallStack(i);
      integer stacklen = llGetListLength(stack);
      if(stacklen)
      {
        llOwnerSay("Call stack:");
        integer j;
        for(j = 0; j < stacklen; j++)
          llOwnerSay("  "+llList2String(stack, j);
      }
      if(llSubStringIndex(llToLower(reason), "heap") != -1)
        llResetDebuggedScript(i);
    }
  }
}

Oh no, I think maybe I've used the wrong word. I'm under the impression that your debug_script() is basically what the suggestion is, except that it is triggered in all scripts in a prim (so if they are dependant they know the script they use has failed) rather than requiring a PIN. I used the word 'dump' for variables instead of 'delete', I mean it would just clear them out, thus giving it the space to do its own error handling.

ie, I have script A with a big list that another script (B) accesses. The list gets too big so suffers a stack-heap collision, as such the list is destroyed and the script_error() event is called in A which resets itself.
The script_error() event is also called in B, which knows its information source is no longer valid and also resets itself.

If no script_error() events were found in the prim/object then it would give the current error as normal.

Debugging info would be really useful, but just having the ability to detect a script failure would be REALLY handy.
However, a PIN might be handy in case a script is renamed...

Although, that said, it's now got me wondering, do we want this? It just occurred to me that if a script can just reset itself, or be reset by a checker script, then it wouldn't require any checks for its memory running low, as it could just rely on this to reset itself instead, thus having a clean empty list, but in poor practise? Hmm, I'd still like it though, even without debugging info you could do things like IM the free memory to yourself so you can quickly work out what caused it.

Whuh? Now this thread is totally confusing. For those of us who weren't following along, what happened?

Wow, thanks for noticing and resurrecting this thread, I'd totally forgotten about it. Poor thing languished for a year.

I'm not really sure it's a good idea to try to recover from errors well enough to call a script_error event handler. How do you recover from a divide by zero? When you have a stack/heap collision, how does it know what to free? It may not be obvious that "if a list made you hit the memory boundary, just free the list". What if memory was extremely tight, and the stack allocations required to call a touch_start event triggered the stack/heap collision? You could go willy-nilly freeing stuff until the script_error event was able to run, but then, how do you know that it won't cause another stack/heap error, resulting in an infinite-crash situation? Ugh...

That's why I wrote it how I did: a script_error event that was triggered in all of the other scripts in the prim. That way, the offending script can be safely stopped, and another script can pick up the error and reset the offending script if it decides that doing so is a good idea.

This was a year ago, and I've learned a lot since. There is a possible security risk if someone else places a script into an prim with my script, picking up error information. The llDebugScriptPin() idea above would work to avoid this situation, but I think just giving relatively terse (but still useful) information like script_error(string script_name, string error_message) would work wonders.

Interestingly, now we have the whole debug window/DEBUG_CHANNEL thing. I imagine it might be possible to listen on DEBUG_CHANNEL. There's still no way to determine what script died, though, and while I haven't tested it, I bet there's still no way to reset a script that blew up.

If all you can do from the debugger is reset the script or hide the error messages, rather than investigate the problem and take corrective action, this would be MUCH simpler:

default
{
  state_entry()
  {
    llTrapAction([
      TRAP_HEAP,TRAP_RESET,
      TRAP_PERMISSIONS,TRAP_IGNORE
    ]);
  }
}