is fully rezzed and all scripts in it are instantiated. This ensures that link
messages will not be lost on rez/region crossing and makes heavily scripted
objects reliable.
When an object was deleted, the remove script instance call was aggregating the scripting events as normal.
This would queue a full update of the prim before the viewer was notifed of the deletion of that prim (QuitPacket)
On some occasions, the QuitPacket would be sent before the full update was dequeued and sent.
In principle, you would think that a viewer would ignore updates for deleted prims. But it appears that in the Linden viewer (1.23.5),
a prim update that arrives after the prim was deleted instead makes the deleted prim persist in the viewer. Such prims have no properties
and cannot be removed from the viewer except by a relog.
This change stops the prim event aggregation call if it's being deleted anyway, hence removing the spurious viewer-confusing update.
Change the reader to wrap old-style definitions in new style wrappers.
Change importer to not check irrelevant data that can't be reconstructed
This removes the last bit of knowledge of XEngine's .state files from core.
pass script state and assembly again properly. Reintroduce respecting tht
TrustBinaries flag. Changes the interregion protocol! No version bump
because it was broken anyway, so with a version mismatch it will simply
stay broken, but not crash. Region corssing still doesn't work because
there is still monkey business with both rezzed prims being pushed across
a border and attached prims when walking across a border. Teleport is
untested by may work.
all scripts are loaded from the same thread, rather than launching a
new one for each script. This is only marginally slower, but avoids the
race condition that led to script engine failure.
debug pane. This will still use DEBUG_CHANNEL currently, since it is not
fully implemented. This also removes the "Compiled successfully" message
that pops up in the viewer.
|Date: Wed, 5 Aug 2009 09:51:52 -0700
|Subject: [PATCH] Closed two major memory leaks for scripted objects
|
|Two major memory leaks for the scripted objects were fixed
|- One leak had to do with remoting acrossing app domains. When a script and
| its controlling agent communicate across an application boundary, it calls
| functions on a stub proxy object that then invokes the remote method on
| the object in the other app domain. These stub objects (two for each script)
| were setup to have infinate lifetimes and were never being garbage collected.
|- The second leak was the result of adding a scene object part instance method
| to a scene event and never removing it. This cause the event's delegate list
| to maintain a link to that object which is then never freed as the scene event
| object is never destroyed.
Patch applied, please direct feedback to me. Possible issue: Longtime idle
scripts like vendors may fail.
After noticing on several occasions that the thread counts
we see when running OpenSIm were bordering on the astronomical
I decided to seriously investigate.
After much poking I discovered that the problem is actually very
simple. The XEngine secition of the example ini says that the
timeout for an iden thread is in seconds, and an example value
of 60 is specified. In fact, this is actually resulting in a 60mS
idle timeout, which is not normally enough for a smart thread
to survive. I have added a multiplier to the XEngine constructor
so that the number now matches the published behavior.
This is sent to all root prims of all attachments of an avatar when the
animation state changes. llGetAnimation() can thenbe used to find the
new movement animation. This eliminates the need for fast timers in AOs
of objects from the scene, and of scripts from objects. This facilitates
the development of modules that can register prims with externall servers
for inbound email and XMLRPC. Currently implemented in XEngine only.
Also applying cmickeyb's compiler locking patch, since it seems risk-free.
NOTHING has been deleted or moved off to forge at this point. what
has happened is that OpenSim.Region.Environment.Modules has been split
in two:
- OpenSim.Region.CoreModules: all those modules that are either
directly or indirectly referenced from other OpenSim packages, or
that provide functionality that the OpenSim developer community
considers core functionality:
CoreModules/Agent/AssetTransaction
CoreModules/Agent/Capabilities
CoreModules/Agent/TextureDownload
CoreModules/Agent/TextureSender
CoreModules/Agent/TextureSender/Tests
CoreModules/Agent/Xfer
CoreModules/Avatar/AvatarFactory
CoreModules/Avatar/Chat/ChatModule
CoreModules/Avatar/Combat
CoreModules/Avatar/Currency/SampleMoney
CoreModules/Avatar/Dialog
CoreModules/Avatar/Friends
CoreModules/Avatar/Gestures
CoreModules/Avatar/Groups
CoreModules/Avatar/InstantMessage
CoreModules/Avatar/Inventory
CoreModules/Avatar/Inventory/Archiver
CoreModules/Avatar/Inventory/Transfer
CoreModules/Avatar/Lure
CoreModules/Avatar/ObjectCaps
CoreModules/Avatar/Profiles
CoreModules/Communications/Local
CoreModules/Communications/REST
CoreModules/Framework/EventQueue
CoreModules/Framework/InterfaceCommander
CoreModules/Hypergrid
CoreModules/InterGrid
CoreModules/Scripting/DynamicTexture
CoreModules/Scripting/EMailModules
CoreModules/Scripting/HttpRequest
CoreModules/Scripting/LoadImageURL
CoreModules/Scripting/VectorRender
CoreModules/Scripting/WorldComm
CoreModules/Scripting/XMLRPC
CoreModules/World/Archiver
CoreModules/World/Archiver/Tests
CoreModules/World/Estate
CoreModules/World/Land
CoreModules/World/Permissions
CoreModules/World/Serialiser
CoreModules/World/Sound
CoreModules/World/Sun
CoreModules/World/Terrain
CoreModules/World/Terrain/DefaultEffects
CoreModules/World/Terrain/DefaultEffects/bin
CoreModules/World/Terrain/DefaultEffects/bin/Debug
CoreModules/World/Terrain/Effects
CoreModules/World/Terrain/FileLoaders
CoreModules/World/Terrain/FloodBrushes
CoreModules/World/Terrain/PaintBrushes
CoreModules/World/Terrain/Tests
CoreModules/World/Vegetation
CoreModules/World/Wind
CoreModules/World/WorldMap
- OpenSim.Region.OptionalModules: all those modules that are not core
modules:
OptionalModules/Avatar/Chat/IRC-stuff
OptionalModules/Avatar/Concierge
OptionalModules/Avatar/Voice/AsterixVoice
OptionalModules/Avatar/Voice/SIPVoice
OptionalModules/ContentManagementSystem
OptionalModules/Grid/Interregion
OptionalModules/Python
OptionalModules/SvnSerialiser
OptionalModules/World/NPC
OptionalModules/World/TreePopulator
OpenSim.Region.Environment into a "framework" part and a modules only
part. This first changeset refactors OpenSim.Region.Environment.Scenes,
OpenSim.Region.Environment.Interfaces, and OpenSim.Region.Interfaces
into OpenSim.Region.Framework.{Interfaces,Scenes} leaving only region
modules in OpenSim.Region.Environment.
The next step will be to move region modules up from
OpenSim.Region.Environment.Modules to OpenSim.Region.CoreModules and
then sort out which modules are really core modules and which should
move out to forge.
I've been very careful to NOT BREAK anything. i hope i've
succeeded. as this is the work of a whole week i hope i managed to
keep track with the applied patches of the last week --- could any of
you that did check in stuff have a look at whether it survived? thx!
This patch fixes the problem where if an object containing a script is
deleted at the same time as an object containing the same script is
rezzed, it can result in the assembly file being deleted after the
second object script initialisation has found it but not started using
it yet, resulting in the script not starting up.
This changeset fixes a race condition where a script (XEngine run) can
startup before a reference is added to it in all of the required
places in the XEngine class. The effect of this is that a script can
sometimes on startup miss script events. For example a script which
starts up and initialises itself from a notecard may never receive the
dataserver event containing the notecard information.
The patch isn't as clean as I'd like - I've split the constructor of
ScriptInstance up so it does everything it did before except
call Startup and post events like state_entry and on_rez. An Init
function has been added which is called after the ScriptInstance
object has been added to the necessary data structures in XEngine.
Happy to rework it if someone suggests a better way of doing it.
Adding Oarfileloaded and EmptyScriptCompileQueue event support which
allows (with a module) for programmatic notification of when a region
objects and scripts are up and running after a server start or
load-oar.
* SceneObjectPartInventory.cs isn't a particularly good name but it's probably not got a long life
* A proper inventory interface to follow
* Parallel changes for other inventory partial classes to follow at a later date
release a direct descendant of the stable 7364, with all the features and
none of the issues.
This omits the following patch chain: r7383 r7382 r7381 r7377 r7375 r7373
r7372 r7370 r7369 r7368 r7367 r7366
- Added two missing caps (UpdateScriptAgent, UpdateScriptTask)
- Added one missing EventQueue event (ScriptRunningReply)
- Changed DNE and XEngine to use this new event
As we only use the mono engine anyway, the "Mono" checkbox is set by
default but doesn't have any function.
Fix: objects being duplicated inventory on detach. Fix: Mad jumping around of
attachments while editing. Fix: Attachments being persisted to database on
login. Fix: Attachments being persisted when changed by a script like
invisprim refresh. Fix: Attachpoint set, but not reset correctly. Fix: prevent
spurious full updates while editing attachments. Several other fixes
Scene. Make the script engines check that the engine name in the
//Engine:language comment is a valid engine and treat it as a normal
comment if it's not.
//DotNetEngine: needs to be written as //ScriptEngine.DotNetEngine: now, since
that is it's real internal name. //XEngine: still works
and makes it use a common set of types in both engine. Fixes the issues with
running both engines and HTTP requests / listens / timers etc..
Also fixes a couple of minor Scene issues and a CTB by nullref.
all methods needed outside the API ststic. Async command processing
is now wholly internal to the API. This sets the stage for the next
convergence step.
BlueWall