Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004756opensim[REGION] OpenSim Corepublic2010-06-07 08:512010-10-04 14:11
Reporterfineman 
Assigned Tojustincc 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0004756: Linked objects deleted straight after unlinking return after server restart
DescriptionThis looks a lot like bug 3059 but I didn't seem to be able reopen that. I have a noteboard that allows addition of new cards which are linked objects. When 'del' is clicked the card is unlinked and deleted. If I delete cards, then log out and back in, everything is fine. A server restart after that is also fine. However if I delete cards, then log out, then a server restart occurs, the deleted cards return as linked object. Those objects when edited claim to have scripts running but they don't seem to, so can't be deleted via the 'Del' function on my board but must be deleted manually. So making the deletion 'stick' seems to require logging out and back in. This frequently won't happen prior to a restart of the sim.
TagsNo tags attached.
Git Revision or version number12841
Run ModeStandalone (1 Region)
Physics EngineODE
Script Engine
EnvironmentMono / Linux64
Mono Versiontrunk
Viewer
Attached Filespng file icon Cards_1.png [^] (252,382 bytes) 2010-06-07 08:52


png file icon Cards_2.png [^] (206,491 bytes) 2010-06-07 08:53


png file icon Cards_3.png [^] (273,344 bytes) 2010-06-07 08:53
png file icon Cards_4.png [^] (161,403 bytes) 2010-06-07 08:53

- Relationships
related to 0003059closedjustincc Non-root prims deleted shortly after delink always reappear on server restart 
child of 0002870new META - Linking issues 

-  Notes
(0015590)
fineman (reporter)
2010-06-07 08:56

Some screen shots showing the sequence.
Cards_1 - I create four cards on the board - they're all linked objects
Cards_2 - I highlighted and deleted card 'One' using 'Del' which delinks and the card kills itself. I then logged out and back in - same screen shot applies.
Cards_3 - Used 'Del' to delete remaining cards, then logged out and restarted sim
Cards_4 - On logging in after restart of sim.
(0015591)
melanie (administrator)
2010-06-07 08:58

This gives a very incomplete picture.

It is a known issue that there are some bugs in the handling of the object local id related to unlinking. They could affect the ability to delete freshly unlinked objects. However, avatar login/logout is unrelated.

Sim restart is relevant. Please try to build a reproduction for this bug. Preferably on master / 0.7Dev
(0015596)
Snoopy (administrator)
2010-06-07 09:28

Sounds exactly like bug 0003059. fineman, can you reproduce that bug the same way Justin describes it in his trouble report?

Probably that fix got broken sometimes before the current 0.6.9 post-fix version.
(0015597)
fineman (reporter)
2010-06-07 10:13

Actually I spent all day investigating this and recreating it. From my experiments, logout and log back in is relevant - it was the only way I could prevent the objects reappearing. It's entirely reproducible for me. I will try to reduce the objects / scripts to the minimum required to recreate the issue. My attempts to reproduce Justin's behaviour do not produce the bug. However, his seemed to be around manual editing of objects where you need to delink the whole set to delete an object from it, whereas mine is scripted delinking and deletion of single objects so maybe they are related but not the same
(0015598)
melanie (administrator)
2010-06-07 10:17

Scripted behavior is totally unrelated to login/logout. Manual action is not.

When objects are unlinked, the viewer's notion of their local id differs from the actual local id. Therefore, a viewer can't delete them successfully. However, a script is independent of the observer.

When a script falls over in the woods and there is no viewer, it DOES make a sound. :)

So, please separate and structure your report to isolate viewer/login related issues (manual interaction) from scripted actions. Provide steps to reproduce manual interaction failures, and provide scripts to reproduce the unexpected scripted behavior. Don't mix the two up. You're helping in the best way possible if you present two distinct workflows, one of them involving ONLY the viewer interaction, one involving ONLY the scripted interaction.

The issues you are describing are very likely TWO distinct issues, one known, one new.
(0015608)
fineman (reporter)
2010-06-10 11:58
edited on: 2010-06-10 12:48

OK, got this down to a problem with scripted deletion of object after breaking links. To replicate:

Create prim1
Create prim2 and insert this script:

 default
 {
   changed(integer change){
        if (change & CHANGED_LINK)
          if (llGetLinkNumber() == 0)
            llDie();
     }
 }

Link with prim1 as root
Wait for ~ 1 min (until 'storing primitive' message on console)
Unlink - prim2 deletes itself
Log out and restart server
On relogging, linked prim has reappeared

This doesn't happen if you manually delete a prim after delinking (which was bug 3059)

Watching the console, trying to replicate 3059 (manually delete delinked prim straight after delinking) I see that there is a 'Storing primitive' message the moment the prim is unlinked from the linkset. When I use the above script, I don't see that same message on unlinking the prim, so maybe somehow the script is preventing that storing from happening?

(0015610)
fineman (reporter)
2010-06-11 02:45

Work around / confirmation:

Modifying the self-destruct script above to wait for more than 60 seconds after the delink (long enough for a 'Storing Primitive' message after the delink) solves the problem:

integer time=0;
integer deleteAfter = 70;
integer tickInterval = 10;

default
 {
   changed(integer change){
        if (change & CHANGED_LINK)
          if (llGetLinkNumber() == 0){
              llSay(0,"Will delete myself in " + deleteAfter + " secs");
              llSetTimerEvent(tickInterval);
          
        }
     }
     
     timer(){
         time += tickInterval;
         llSay(0,(string)time);
         if (time == deleteAfter)
            llDie();
        }
 }

Combining this with either making the prim transparent or moving it to a hidden spot during that 70 second wait may be enough for some use cases.
(0015611)
melanie (administrator)
2010-06-11 08:55

it still needs to be fixed. manual deletion forces persistence, then does the delete. llDie will need to do the same.
(0016770)
justincc (administrator)
2010-09-06 18:43

Hopefully fixed by 3c03352 in Git master.

- Issue History
Date Modified Username Field Change
2010-06-07 08:51 fineman New Issue
2010-06-07 08:51 fineman Git Revision => 12841
2010-06-07 08:51 fineman SVN Revision => 0
2010-06-07 08:51 fineman Run Mode => Standalone (1 Region)
2010-06-07 08:51 fineman Physics Engine => ODE
2010-06-07 08:51 fineman Environment => Mono / Linux64
2010-06-07 08:51 fineman Mono Version => trunk
2010-06-07 08:52 fineman Relationship added child of 0002870
2010-06-07 08:52 fineman Relationship added related to 0003059
2010-06-07 08:52 fineman File Added: Cards_1.png
2010-06-07 08:53 fineman File Added: Cards_2.png
2010-06-07 08:53 fineman File Added: Cards_3.png
2010-06-07 08:53 fineman File Added: Cards_4.png
2010-06-07 08:56 fineman Note Added: 0015590
2010-06-07 08:58 melanie Note Added: 0015591
2010-06-07 09:28 Snoopy Note Added: 0015596
2010-06-07 10:13 fineman Note Added: 0015597
2010-06-07 10:17 melanie Note Added: 0015598
2010-06-10 11:58 fineman Note Added: 0015608
2010-06-10 12:48 fineman Note Edited: 0015608
2010-06-11 02:45 fineman Note Added: 0015610
2010-06-11 08:55 melanie Note Added: 0015611
2010-09-06 18:43 justincc Status new => resolved
2010-09-06 18:43 justincc Resolution open => fixed
2010-09-06 18:43 justincc Assigned To => justincc
2010-09-06 18:43 justincc Note Added: 0016770
2010-10-04 14:11 chi11ken Status resolved => closed


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker