What causes scripts to go into a non-running state?

Does anyone have (or could anyone point me to) a handy list of the events/scenarios which will cause all of the scripts (in all of the prims) in an object to go into a non-running state?

As far as I'm aware there's only:

a) the object moved into no-script land,
b) the user stopped scripts with the tools menu,
c) the object got deleted

Other things that stop scripts do so only one at a time - I think.

Thanks Yumi, possibly your scenario (a) is what is causing my problem. I got the impression from other forum posts that entering a no-script area would just 'suspend' running scripts, I will try and test this to see exactly what does happen.

d) the script was running its state_entry() event when the sim crashed
e) math error (division by zero, llAcos(2.0), etc...)
f) script ran out of memory

OK ty Jesrad, option sounds a possibility as well, the scripts are doing a lot of vector and rotation calculations. Still a bit puzzled as to why all of them would stop running at the same time though. When I've seen script errors (stack/heap collision etc) actually happen in-world (with helpful accompanying error message) before, its usually only the single offending script that needs to be restarted.

I've had trouble with llSetScale being used in child prims - IIRC it can randomly freeze the entire linkset.

I'm not using llSetScale(), but I am using llSetPrimitiveParams() extensively in child prims to adjust position and rotation. The problem also only seems to occur in objects which have physics enabled, although this may be something of a red herring.

I've not had any freezing trouble with llSetPrimitiveParams altering position and rotations on non-physics-enabled prims, I guess it could be the physics.

Another thing that sends a script to not running: giving it to another prim using llGiveInventory.

If you place a script that did not compile into an object it will go into a not-running state.

Similarly if you edit a script already in an object and the compile fails and you then close it it will go into a not-running state.

Thanks to all who suggested possible causes, I have investigated further by placing my physics-enabled object in a deep pit (to stop it escaping) and letting it flail about for a few hours. It would seem that at some point 'something' happens which causes all the scripts to enter a non-running state, even those which weren't doing anything at the time. Click on 'set all scripts to running', and the object continues on happily, apparently none the worse for wear.

Problem transferred to 'pending' pile.

I've had this happen to some animals. Sometimes when left to wander alone, I would find them "stuck", with the scripts in the root prim in no-run state Apparently this is caused by collisions, possibly during a sim crash.

Yup, that sounds consistent with what I have been seeing, although I do not think there was any sim crash, it was just collisions which triggered it. Sigh, now I have to put some sort of black box recorder in my object to try and work out what type of collision causes this.

I've seen this with my self-roaming objects. In fact, I sometimes find them with ALL SCRIPTS set to no-run, in every prim -- Root or child. Even the simple scripts that just control animations/visual effects and in no way do anything intense.

I've never actually observed one hard-crash or whatever it's doing to get it into that state though...

Exactly as Jigsaw describes...