Regression from commit ed162a10 (Fri Oct 5 13:50:12 2012)
We had started listening for the client login event for attaching the sound trigger event rather than OnNewClient
Addresses http://opensimulator.org/mantis/view.php?id=6453
Many thanks to danbanner for identifying the exact commit where this went wrong, which made identifying the fix easy.
This is for bug hunting purposes where thread aborts may be causing dangling lock issues and subsequent vm crashes on mono (with ReaderWriterLockSlim, etc.)
We do this in OpenSim.exe to hide output when unmanaged dll are scanned by mono addins. Libomv has hard-coded path to "." for the openjpeg libraries, causing output to the console when they are scanned. We will cover this up for now, then look at getting libomv to look for the libs outside the "." later.
dumping of physical vehicle parameters (out of Bullet) on each
simulation step and to optionally scale vehicle angular velocity
by the time step. The latter looks to be part of a difference
between angular parameters for ODE and BulletSim. SL docs say
angular velocity is measured in radians/timeScale. Not sure if this
is different than what ODE does.
While fixing the above, add methods to physical body and shape pointer
wrapper so routines won't have to know that IntPtr.Zero means no
physical instance.
Fix problem with physical linksets failing after a few sits and
unsits by properly restoring child prom positions for compound
linksets after multiple selection and deselections.
This is in relation to http://opensimulator.org/mantis/view.php?id=6311
This is after further analysis which shows the viewer expects the server to move the folder for #RLV give but then should be renaming the folder itself.
For some reason this is not happening, possibly because we are not sending BulkUpdates or because we are not using transaction IDs properly.
This needs to be fixed in the future.
However, moving the folder even if the rename isn't correctly triggered in the viewer seems preferable to disabling this code altogether.
When an object is removed, its scripts are stopped and then the thread running them is aborted if stop takes too long.
However, it appears that aborting a thread at just the wrong moment when it is obtaining a ReaderWriterLockSlim lock can leave this lock in an inconsistent state.
One symptom of this is that mono leaps to 100% cpu and a vm thread dump reveals lots of threads waiting for a ReaderWriterLockSlim lock without any thread actually holding it.
This is probably the same problem as encountered originally in commit 12cebb12
This commit looks to plaster this problem by putting lock obtaining methods inside finally blocks which should be uninterruptible by thread aborts.
BlueWall