Jump to content

Resetting scripts in a prim


Gregory McLeod
 Share

You are about to reply to a thread that has been inactive for 3536 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

I know that you cannot reset a script from another script unless it is running.

Maybe I was not clear in what I want to achieve.

There is a build function which allows you to recompile all the scripts in a prim but not one which selectively recompiles just one script, am I right?

The problem is your solution requires someone , usually me, to go online and reset or recompile the scripts  which given SL 24x7x365 could mean any time and I object to getting up at 2am on  a Sunday.

Thanks anyway

Link to comment
Share on other sites

You can reset just one script in a prim the way Rolig said
There is no reason for recompile, reset will reset the script and all allocated memory

Anyway you are just treating the symptom
To cure the problem you should change the script so that it will not overflow memory

:smileysurprised::):smileyvery-happy:

Link to comment
Share on other sites

Have to add an agree to Dora there - if a script is giving you sleepless nights then find out why and rewrite to fix it =^^= Back in the Real World (!) when I did the 'always on call support nightmare' thingie a good part of my job was to make sure those 3AM local calls (which due to the nature of the company it could come any time local to them) were kept to a minimum :)

If that meant a week of sitting up testing stuff before releasing it into the wild it was well worth it.

 

Link to comment
Share on other sites


Rolig Loon wrote:

Ah... You didn't specify that you wanted a way to do it by script.  You can't do that.  The only way is to reset it manually as I described (or, as Dora recommends, to find out why it stalls and fix THAT problem).

I had a thought.  Which I'm not suggesting is a good idea.  But I wonder if it would be possible to use llRemoteLoadScriptPin to 'silently replace' the 'failed and needing reset' script.

Link to comment
Share on other sites

I suppose it depends on how you do the cost/benefit analysis.  I think it's more satisfying to actually solve the problem than to grab another defective copy of the script and pop it in every time one locks up, but that's just me. 

Link to comment
Share on other sites


Rolig Loon wrote:

I suppose it depends on how you do the cost/benefit analysis.  I think it's more satisfying to actually solve the problem than to grab another defective copy of the script and pop it in every time one locks up, but that's just me. 

Okay.  You suggest opening the object and resetting the script to get the defective copy running again.

But when I ask if this remote load thing is even possible, not something I'm suggesting is a good idea... you go off into personal satisfaction and cost/benefit analysis.

What's up with that?

I just asked a question.

Link to comment
Share on other sites

Sorry, Qwalyphi.  I wasn't aware that you were asking whether it was possible. I thought you were making a suggestion. I imagine it is, although I haven't tried it. I can't think of any other way to reset a jammed up script other than doing it manually.  All I said was that if your method were possible -- an interesting possibility -- my own choice would still be to fix the existing script instead of replacing it every time it locks up. 

Link to comment
Share on other sites


Rolig Loon wrote:

Sorry, Qwalyphi.  I wasn't aware that you were asking whether it was possible. I thought you were making a suggestion. I imagine it is, although I haven't tried it. I can't think of any other way to reset a jammed up script other than doing it manually.  All I said was that if your method were possible -- an interesting possibility -- my own choice would still be to fix the existing script instead of replacing it every time it locks up. 

Thanks Rolig.  I agree that it's better to fix things rather than hovering waiting to replace things.  Although Amazon tells me that if their Kindle ap starts working again after I reboot windows things are working normally.  Which is to say it's broken and they aren't going to bother to fix it.

Link to comment
Share on other sites

I agree the correct solution is to rewrite the script.

However that brings up a further question what do you change in a script that causes stack-heap collisions rarely enough to never do it while testing.

Can you suggest a way to determine what is causing the stack-heap collision?

Link to comment
Share on other sites


mikka Luik wrote:

Snip

If that meant a week of sitting up testing stuff before releasing it into the wild it was well worth it.

 

But what do you do if after weeks of testing which have never resulted in a stack-heap collision to find out what causes it in real use?

Can you monitor memory sufficiently often enough and report on your findings without causing a stack-heap collision?

Link to comment
Share on other sites


Gregory McLeod wrote:

I agree the correct solution is to rewrite the script.

However that brings up a further question what do you change in a script that causes stack-heap collisions rarely enough to never do it while testing.

Can you suggest a way to determine what is causing the stack-heap collision?

One technique I use is to stick in lots of llOwnerSay((string)llGetFreeMemory()); and run the script a few times to see if there's any particular point where the amount of memory used consistently increases.   If there is such a point, that's probably the problem -- if the increase is small, it's probably not going to show up when you're testing it, but will eventually crash the script.   Are you adding items to a list each time the script runs?    That's eventually going to cause problems.

If the worst comes to the worst --   I hesitate to recommend this, because it is such a kludge -- and you really can't identify the root cause, then why not check llGetFreeMemory() every time the script runs and reset it if you're getting too close to the danger zone?   But you shouldn't need to do that.

 

Link to comment
Share on other sites

Basically I would use llGetUsedMemory() or llGetFreeMemory() in a llOwnerSay() to report the status over time
You could also save reports in another script, IM or email yourself so you don't have to be on line all the time

In the report I would include list's sizes and what else is appropriate

I don't know the actual script but if it is a list that grows too large I would limit it's size and possibly split the data between more scripts

Link to comment
Share on other sites

That kldgy technique certainly has merit but there are other criteria would have to be set before restting. Its a question of maintaining the security of both the prim and it's scripts and a website link password. I am sure I can work round that with come obfuscating embedded data fields.

I think I prefer the former investigative approach and then correct the script.

The problem is the unpredictablity of the changes to stack or heap within the script. Time will tell by investigating where the memory is being absorbed. I want to avoid if possible the problem of multiple llOwnerSay(...)  function calls as the limit is the storage available in the first place is tight. I have already split the original script into 2 scripts containing like facilities together UI and External comms.

 

Link to comment
Share on other sites

The llOwnerSay calls should, though, give you an idea of where the problem areas are.    Certainly whenever I've been investigating this sort of issue in my scripts,  it's never taken too long to identify where in the script the memory is being eaten.  

One general tactic to use is to make sure you clear all variables as soon as you've finished with them, rather than waiting for the garbage collector.  Emply list temp before you leave the event where you call it.

Otherwise, Dora's suggestion of splitting the script in two may be the best idea.    If, even after identifying the problem, you simply don't have much free memory to play with, that's usually the safest plan.

However, that can be a lot of extra work, so you might try some of Becky Pippen's suggestions here.   Additionally, I would take a careful look at any user functions you've written, particularly if they call lists. If you only use them once or twice in the script, it may well be less expensive simply to put the code in the events.   Similarly, populating lists is often best done at runtime. This is because of the way LSL  deals with globals -- it makes a complete temporary copy when they're called, so everything is twice as expensive.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3536 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...