|Anonymous | Login | Signup for a new account||2022-01-17 12:35 PST|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008519||opensim||[REGION] OpenSim Core||public||2019-04-16 07:54||2022-01-10 03:36|
|Platform||Operating System||Operating System Version|
|Target Version||Fixed in Version|
|Summary||0008519: Delete unlinked objects from in world does not always persist|
|Description||An old bug seems to have resurfaced for me: 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.|
This issue was previously fixed a few years ago in commit 62b3bdf0fc7a64dd9b845eb27fa8e1a2a1866c2b but seems to be back now.
|Steps To Reproduce||1. Rez an object that has multiple links to the ground.|
a. In my test I had an object with 128 links and shift copied it a few times so I had a grand total of appx 1200 prims.
2. Unlink (all) the object(s)
3. Select all the objects at once and delete the whole group
4. Wait until every thing is deleted and there are no more objects being created in the trash.
5. Log out and shut down then restart OpenSim
6. Log back in and if the issue was triggered then random pieces of the build will still be hanging around and not properly persisted when deleted.
a. This is also visible to other avatars to after they relog.
b. The objects can eventually be deleted entirely but it may take a few tries, relogs, and server restarts.
|Tags||No tags attached.|
|Git Revision or version number|
|Run Mode||Standalone (Multiple Regions)|
|Environment||.NET / Windows64|
|Attached Files||Prim Tests.jpg [^] (1,028,348 bytes) 2019-04-29 22:35|
|please stop adding relationships that you don't know anything about|
edited on: 2019-04-16 08:09
One of the relationships I added was from a report that I made for this same issue a while back (0006175) and that report had those other two relationships added to it. I added those relationships because it appeared to be the same issue to me. Perhaps it isn't the same issue (not the same underlying cause) and if that's the case I apologize. But I didn't add the relationships without thinking about it and coming to the conclusion that it appeared to be the same issue.
1200 prims (even 256) can take a while to process, even after all visible action done.
The visible aspects are done relative fast to keep viewers happy etc., rest goes on in background, and may get killed on regions shutdown
As before, give a lot of time after such a operation, before shunting down the region, until we change that code such it does hold the shutdown process
Same applies to assets loading, they take time to actually get into grid, and that does get killed on shutdown.
And who knows what more ;)
Thanks, I will keep that in mind. I would like to note though that I've seen it happen on linksets with very few prims (Last time I saw it was on a small HUD I had on ground editing it at 4 prims) on a grid local to my network (Robust.exe, OpenSim.exe, MySQL all on the same LAN as me) on a sparsely populated region.
Will keep an eye on it and continue testing this. Maybe it was possible I was being a bit too impatient before taking the objects / deleting them ;)
|Running backup until it completes instantly is usually a sure way of getting all object updates in before a shutdown. I run at least one on the automated systems to be sure.|
@tampa - Yes, I always make sure to run the backup command before shutting down; have even added this command to my shutdown_commands.txt as well in this form:
change region root
NO backup may not help... different code paths
If it has a lot to do, that delay will help, if not, not really...
edited on: 2019-04-21 03:32
I encountered this issue again today, I previously had unlinked something, then let it sit for about 30 minutes before taking it/deleting it, then waited about 10 minutes before restarting OpenSim but the some of the objects pieces still reappeared.
edited on: 2019-04-26 22:31
I tried git bisect to see if I could pin point the location where this first started happening but it gave me a commit that I'm not sure makes sense or not because it is a commit that changes some things with YEngine.
One thing that I did notice while testing though was that when the issue occurs; the prim count in About Land > Objects isn't decremented properly. I started testing on a region with nothing on it, 0 prims used as reported by About Land and then started building, rezzing things out, and shift + drag copying prims and then unlinking them. Sometimes not all the objects will unlink and will be stuck in a state where they can't be unlinked at all. If all the objects are deleted or taken it will visually appear that nothing is left on the region but looking back at About Land > Objects tab will show that the region is still using some prims. Upon restart of OpenSim those objects that were "stuck" linked will be back on the region again and will be in the unlinked state, can be deleted, the prim counts will properly show 0 again, and those prims will remain deleted on the next restart after that.
I was using YEngine when I was testing this by the way... Might need to go back and test this again using XEngine just to see if by some strange reason it's the choice of scripting engine that could be causing this and possibly test before and after the suspected git bisect commit to see if it was just a false lead or not.
$ git bisect good
a83b7a292bc3c18c9c6a1aa17cfc2622b99804c4 is the first bad commit
Author: UbitUmarov <firstname.lastname@example.org>
Date: Mon Apr 15 23:32:22 2019 +0100
mantis 8518: Yengine; we can't wait for GC (worse finalizers) to count released memory of some local variables, so add a pseudo free; fix memory account on timeslice rentry; change the folder for the debug IL files; fix memory usage on reset. This changes will only take effect on new compiles
:040000 040000 8bd389e54432a4268b048b8856fc0b068d2bbb6e 9c5f65b81c2363ff3057088551c6cec608d8058b M OpenSim
|guess what.. I could not repo, using packs of 1024 basic unscripted prims|
edited on: 2019-04-29 22:43
The issue is random and I can not yet pinpoint exactly what I'm doing that is causing it to happen... And it doesn't happen consistently every single time so that is making this issue somewhat difficult to test for. I only mentioned the commit that git bisect found for the sake of documenting what I have seen over the course of trying to track this down. I don't think that commit makes any sense in the context of this issue but stranger things have happened.
I have uploaded a step by step illustration of what I did and what I observed on the group that failed testing since it is a bit difficult to explain this with words.
In my testing I noticed that the group with the shift drag copied prims was the group that seemed to fail the most consistently (Group 3 in test step 3c below). You will know that the issue is triggered when not all the prims unlink and it becomes impossible to retry unlinking them.
Note: The number of prims I chose was arbitrary but I tried to
keep it consistent for each group of prims tested
1. Test on a completely empty region. This just makes it easier to determine if there are any prims that weren't actually deleted but aren't visible to the viewer by checking About Land > Objects to see if the prim count is greater than 0 after deleting all the prims. In my tests this region was the only region I was running.
2. Made a group of 375 linked unscripted cubes (I had a 5x15x5 "rectangle" of them) and then took it to inventory
3. Rez the test object out in 3 groups
a. Group 1: with just the single rezzed object of 375 prims
b. Group 2: rezzed out multiple copies from inventory, did not shift drag copy the previous group, and did not shift drag copy the newly rezzed group. I did 6 inventory rezzes in this group for a total of 2250 prims
c. Group 3: rezzed out one copy of the object and shift drag copied it 6 times for a total of 2250 prims
4. Unlink each group of prims by highlighting the entire group and unlinking
a. You'll know the issue is triggered if some of the prims refuse to unlink
5. Highlight each group of now unlinked prims all at once and delete them 1 group at a time
6. Wait for OpenSim to stop sending things to the trash then logout and restart OpenSim
7. Upon restart and relog the prims that refused to unlink will be back, will be unlinked, and can be deleted.
This test may need to be repeated a number of times before it'll show up because it doesn't happen consistently
|I still see this issue in master|
|sounds more like the typical select issues that actual delete code|
|That may be; I noticed that if I have multiple objects selected and move them around, sometimes some of the objects disappear resulting in a broken looking object. If I delete the selection, and then restart OS, the objects that disappeared reappear on the region minus the parts that were deleted that didn't disappear. I've seen this happen on a selection as few as 5 or 6 objects (totaling maybe around 20 or 30 prims, nothing outrageous) but the issue seems more easily triggered the more objects / prims are selected.|
edited on: 2022-01-05 18:17
Still see this issue on master beyond the 0.9.2 release.
I've noticed a new piece to the issue though: I was working on a small build earlier of 1 object/14 prims and unlinked it to do some rearranging of things, and then relinked it with a different root prim and took it back to inventory. On next start up of OpenSim, the object reappeared on the region where I was working on it earlier, except the prim that I had relinked it to was missing, and the rest of the object was completely unlinked.
I am now wondering if at least part of the issue is that the simulator is (sometimes?) only taking into account the root prim when deleting or taking objects back to inventory, and not their child prims.
To be clear, the object I receive back in inventory is complete, nothing is missing if I rez it back out, but the version of it that was to be removed from inworld when taking/deleting it ends up in that state back in region.
|test again.. no repo :(|
This issue is very random; you probably won't see it unless you build on a regular basis.
I am just a little bit surprised that I seem to be the only one who's noticed the issue.
It doesn't seem to be viewer or user specific. I've seen it happen under Firestorm, Singularity, and Alchemy so far, and not just for me, I have seen remnants of builds by other people on my grid as well... It just leaves a mess when we're trying to build up a new region and we are constantly linking and unlinking things as we design.
|I wonder if it is related, but I did notice that on certain regions I build on quite regularly and delete things after a restart some of the parts are back even though I run backup before each shutdown to make sure everything is saved to disk. They are, come to think of it, parts of linked objects, but not always. I wonder if this is down to some timing issue running the delete routines for the objects tripping over themselves or not quite actually running because they are issued to quickly. Just a guess(cause the faster the cpus get and the weirder mono becomes this keeps coming up lately).|
|I am running OpenSim on Win 10 x64 with .NET 4.8 for the record. It may not be strictly a Mono thing, but that does possibly bring up the question of does this only happen on .NET and not under Mono, or does it happen only on Windows (vs. Linux) .NET?|
|i did test on win10 64, .net4.8 runtime also|
|2019-04-16 07:54||mewtwo0641||New Issue|
|2019-04-16 07:54||mewtwo0641||Relationship added||related to 0006175|
|2019-04-16 07:54||mewtwo0641||Relationship added||related to 0007064|
|2019-04-16 07:54||mewtwo0641||Relationship added||related to 0003059|
|2019-04-16 07:56||UbitUmarov||Relationship deleted||related to 0006175|
|2019-04-16 07:56||UbitUmarov||Relationship deleted||related to 0007064|
|2019-04-16 07:56||UbitUmarov||Relationship deleted||related to 0003059|
|2019-04-16 07:58||UbitUmarov||Note Added: 0035133|
|2019-04-16 08:08||mewtwo0641||Note Added: 0035134|
|2019-04-16 08:09||mewtwo0641||Note Edited: 0035134||View Revisions|
|2019-04-17 05:15||UbitUmarov||Note Added: 0035138|
|2019-04-17 05:37||mewtwo0641||Note Added: 0035142|
|2019-04-17 05:56||tampa||Note Added: 0035143|
|2019-04-17 06:09||mewtwo0641||Note Added: 0035144|
|2019-04-17 06:47||UbitUmarov||Note Added: 0035146|
|2019-04-21 03:31||mewtwo0641||Note Added: 0035159|
|2019-04-21 03:32||mewtwo0641||Note Edited: 0035159||View Revisions|
|2019-04-26 22:25||mewtwo0641||Note Added: 0035177|
|2019-04-26 22:26||mewtwo0641||Note Edited: 0035177||View Revisions|
|2019-04-26 22:31||mewtwo0641||Note Edited: 0035177||View Revisions|
|2019-04-29 07:22||UbitUmarov||Note Added: 0035178|
|2019-04-29 22:34||mewtwo0641||Note Added: 0035179|
|2019-04-29 22:35||mewtwo0641||File Added: Prim Tests.jpg|
|2019-04-29 22:40||mewtwo0641||Note Edited: 0035179||View Revisions|
|2019-04-29 22:42||mewtwo0641||Note Edited: 0035179||View Revisions|
|2019-04-29 22:43||mewtwo0641||Note Edited: 0035179||View Revisions|
|2020-03-01 04:50||mewtwo0641||Note Added: 0036229|
|2020-03-01 08:05||UbitUmarov||Note Added: 0036230|
|2020-03-01 17:53||mewtwo0641||Note Added: 0036237|
|2022-01-05 18:16||mewtwo0641||Note Added: 0038318|
|2022-01-05 18:17||mewtwo0641||Note Edited: 0038318||View Revisions|
|2022-01-05 18:37||UbitUmarov||Note Added: 0038319|
|2022-01-09 19:25||mewtwo0641||Note Added: 0038321|
|2022-01-09 20:49||tampa||Note Added: 0038322|
|2022-01-09 22:47||mewtwo0641||Note Added: 0038323|
|2022-01-10 03:36||UbitUmarov||Note Added: 0038324|
|Copyright © 2000 - 2012 MantisBT Group|