|Anonymous | Login | Signup for a new account||2019-10-14 17:03 PDT|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006175||opensim||[REGION] OpenSim Core||public||2012-08-18 03:05||2019-04-16 07:54|
|Product Version||master (dev code)|
|Target Version||Fixed in Version||master (dev code)|
|Summary||0006175: Rez an object from inventory and later remove it does not always persist|
|Description||When rezzing an object from the inventory to the ground, unlinking, and then later attempt to remove the object; it does not always persist and will be visible again upon a relog.|
|Steps To Reproduce||I am running git r/20019 (19417fc) for these steps|
1. Rez an object that has multiple links to the ground. (In my case it is usually attachments that I've rezzed from inventory to unlink and make modifications on; although I am unsure if this makes a difference or not)
2. Unlink the object and spend a little while (perhaps 10 or 15 minutes) making modifications such as shift copy of prims, adding scripts, changing prim sizes, textureing, etc.
3. Either delete the finished object or take the it back into inventory.
4. Upon relog the object will reappear (or perhaps random parts of the object if it was deleted and not linked before hand).
a. This is also visible to other avatars to after they relog.
b. If attempting to take the object again or delete again it will be back again after another relog.
c. The object will persist until server restart where it will reappear again, but can finally be gotten rid of for good by means of a delete or take to inventory.
|Additional Information||A few things that I have noticed when the issue triggers:|
* When removing a multiple selection of prims, only the root prim of that selection seems to persist removal, resulting in the appearance of most of the rest of the object still being there upon relog.
* When examining the MySQL database at the prims table using SELECT count(*) FROM `databasenamehere`.`prims` the prim count goes down by one even though multiple prims may be selected for removal.
* If the server is restarted, the affected objects can be removed, and it will be persisted.
Unfortunately it doesn't it trigger consistently applying the above steps and I've not yet found a way to consistently trigger it.
|Tags||No tags attached.|
|Git Revision or version number||r/20019|
|Run Mode||Standalone (Multiple Regions)|
|Environment||.NET / Windows64|
Here's how to reproduce this bug:
1. Rez two boxes: A, B
2. Run console command "backup"
3. Link A and B. (Let's assume that B is the root prim of the new group)
4. Delete the object
5. Restart the region
6. Expected: both A and B are missing. Actual: A has reappeared.
Reason: when A and B are linked, the database isn't updated immediately. So A still has its old SceneGroupID in the database. Therefore, when the combined object is removed from the scene, RemoveObject() deletes only prim B from the database because it's the only one that has the expected SceneGroupID.
The solution is to persist the object to the database before deleting it. Scene.UnlinkSceneObject() already had similar code (that persists an object before deleting it), but it was used only if the object had been previously delinked. Now it's also used if the object had previously had "foreign" prims linked to it.
|Fixed by 62b3bdf in Git master|
|2012-08-18 03:05||mewtwo0641||New Issue|
|2012-08-18 04:32||DMX04||Issue cloned: 0006176|
|2013-03-22 21:26||mewtwo0641||Relationship added||has duplicate 0006176|
|2014-03-24 03:43||orenh||Note Added: 0025550|
|2014-03-24 03:43||orenh||Relationship added||has duplicate 0003059|
|2014-03-24 03:47||orenh||Note Added: 0025551|
|2014-03-24 03:47||orenh||Mono Version||None => 3.1|
|2014-03-24 03:47||orenh||Status||new => resolved|
|2014-03-24 03:47||orenh||Fixed in Version||=> master (dev code)|
|2014-03-24 03:47||orenh||Resolution||open => fixed|
|2014-03-24 03:47||orenh||Assigned To||=> orenh|
|2014-03-28 01:17||orenh||Relationship added||has duplicate 0007064|
|2014-07-29 13:43||chi11ken||Status||resolved => closed|
|2019-04-16 07:54||mewtwo0641||Relationship added||related to 0008519|
|2019-04-16 07:56||UbitUmarov||Relationship deleted||related to 0008519|
|Copyright © 2000 - 2012 MantisBT Group|