Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007720opensim[GRID] Inventory Servicepublic2015-09-07 15:392019-02-06 11:50
Reporterdanbanner 
Assigned Todanbanner 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOpensim 0.8.2 devOSlinuxOS Version
Product Versionmaster (dev code) 
Target VersionFixed in Versionmaster (dev code) 
Summary0007720: Changing permissions on wearables destroys the item
DescriptionCreating a shirt or undershirt works fine and asset uuid is fine until permissions are changed and then the asset uuid becomes 00000000-0000-0000-0000-000000000000 This probably is occuring for other wearables but i have only tested this on shirts and undershirts
Steps To ReproduceCreate a shirt or undershirt
wear the item and add a texture
set full perm then clear cache and relog
asset uuid is now 00000000-0000-0000-0000-000000000000

Additional InformationI have tested this on current dev builds on osgrid and also tested on OSCC grid running f4dfdbb from june 28th and the same thing occurs.
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
Physics EngineODE, BulletSim
EnvironmentMono / Linux64
Mono Version3.2
Viewerany
Attached Files

- Relationships

-  Notes
(0029450)
danbanner (manager)
2015-09-07 17:28

Ive noticed that just creating the asset and changing permissions does not seem to end up with a zero uuid, im seeing it happen 100% of the time tho if i wear the item, add a texture, etc then change perms.

Tested this with eyes too and it seems to happen as well
(0029451)
Jim Jackson (reporter)
2015-09-07 17:38

I can confirm this is true for tattoos also. I created a tattoo, changed the permissions, and upon relog get the message "Failed to find clothing named ARMPIT HAIR TATTOO in the database." I can wear the item until relog, upon relog it is no longer useable.The messages come back with each relog until the item is purged from inventory. Doesn't seem to matter if I clear my cache or not, I get the same results. The relog seems to trigger it.
(0029457)
LaniGlobal (reporter)
2015-09-07 20:55

WORKAROUND:
1. Create the body part.
2. Put the body part into the contents of a rezzed prim
3. Change the permissions of the contents of the prim.
4. Take the body part from the contents of the prim

REPRO:
1. I confirm the danbanner report.
2. The permission change to a new body part in inventory causes fail.
3. I have found it reproducible in the following environment:
Singularity Viewer (64 bit) 1.8.5 (5617) Jan 29 2014 00:07:05 (Singularity)
Grid: OSGrid
Built with MSVC version 1700
OpenSim 0.8.2.0 Dev
8aa75f225b83acb5064145d51f724e37875602be
r/26119 (Unix/Mono)
(0029461)
Diva (administrator)
2015-09-09 20:17

FYI I cannot repro this on standalone
(0029462)
Mata Hari (reporter)
2015-09-10 08:24

Confirmed that this is reproducible on Refugegrid as well
(0029463)
Mata Hari (reporter)
2015-09-10 08:42
edited on: 2015-09-10 08:55

Even scarier...

Rez a cube to ground
Set permissions to full perm
Take object into inventory
Right-click it in inventory and select properties
Change it to no-copy, no-trans, no mod
Rez it to ground or send it to someone
Inspect the perms: they will still be the "old" perms from when it was previously rezzed to ground (ie it will still be full perm even though you changed it to remove all perms)

The above doesn't report null key UUID though...the UUIDs change but don't null

If this isn't related to this Mantis' issue please let me know and I will log a separate report for this.

Tested under OpenSim 0.8.2.0 Dev f6d79c7cbb 30-Aug-2015 r/26206 using Firestorm 4.7.3 (47323) Aug 18 2015 03:46:39 (Firestorm-Releasex64) with OpenSimulator support

(0029466)
UbitUmarov (administrator)
2015-09-11 07:28

Cause seems to be the cache added to some methods in OpenSim\Services\Connectors\Inventory\XInventoryServicesConnector.cs. Sounds like that cache doesn't cover all the paths that modify items
(0029467)
Diva (administrator)
2015-09-11 07:37

Ubit, I have been unsure of whether to fix this now or after the AVN merge. Let me know if fixing this will make your life harder.
(0029468)
Diva (administrator)
2015-09-11 08:38

ok, so I'm trying this on a test grid and I also can't repro. Maybe I'm missing something. danbanner what does it mean "add a texture"? -- that's the only step I didn't do because I don't know what that means.
(0029469)
Diva (administrator)
2015-09-11 09:50

[09:50] <cia-opensim> opensim: diva * r29aaf5564f52 OpenSim (2 files in 2 dirs):
[09:50] <cia-opensim> Mantis 0007720: AssetXferUploader was setting AssetID to UUID.Zero. Before that wouldn't matter (item would be a terminal object) but with the introduction of the item cache, it matters, because the object in the cache was being modified to have AssetID=UUID.Zero. Also keeping the item cache consistent when item properties change.
(0029470)
Mata Hari (reporter)
2015-09-11 11:06

Not sure if this also requires the grid Robust server to be updated but I did the following test using your new commit using Firestorm 4.7.3 (47323) x64 Opensim version

1. Opened my inventory
2. Right-click on an inventory folder and from drop-down menu selected New Clothes > New Alpha Mask
3. Named it "new alpha test"
4. Right-clicked it and selected Copy Asset UUID, then pasted that in chat to confirm that it has a valid UUID....it does
4. double-clicked the item in inventory to wear it
>> Viewer responds with an error message pop-up "Failed to find clothing named "new alpha test" in the database; however the item is worn
5. right-click on it in inventory and selected "Edit" from the drop-down .. viewer enters clothing edit mode
6. Clicked the check box to enable Lower Alpha and simply left it at the default black texture
7. Clicked "Save"
>> Viewer again pops up error message "Failed to find clothing item named "new alpha test" in the database
8. Double clicked it in inventory to unwear it
>> Viewer yet again pops up the same error message
9 Right-clicked it in inventory and "Copy Asset UUID" and pasted....asset UUID is valid but different (which is expected)
10. Right-clicked it, selected properties, and changed perms
10. Logged out
11. Logged in again
>> on login again received the same error message even though the item isn't worn
12. Right clicked it, Properties> checked perms -- this time they correctly remembered the new perm setting
13. Right-clicked it and Copy Asset UUID > again it now supplies a valid UUId so that part of the bug is also fixed
14. Double-clicked it to wear it....yet another identical error message pop-up but it appears to mask lower as intended
15. Removed it....another error message
16. Wore my normal alpha mask...*it* then generated the same error message ***including the "new alpha test" name instead of my normal alpha mask's name*** when I wear it where it never did so in the past.
17. Unwearing that one also generated the same error message, again with the incorrect name
18. Re-wore my normal alpha, logged out, logged back in....it no longer generates an error message
(0029471)
Diva (administrator)
2015-09-11 11:08

You may have a dead item in your Current Outfit folder.
(0029472)
Mata Hari (reporter)
2015-09-11 11:26

Interestingly, when I check my Current Outfit folder I see a folder link for every single outfit I've changed to for the last few weeks. I manually deleted all of these, relogged, then wore an outfit. Then wore another outfit. The Current Outfit folder updates itself correctly with the actual items worn but does not remove the link to the previous outfit's folder. If I wear a variety of my stored outfits it gradually adds links to those folders to the current outfit folder which are never removed unless I do it manually (but the actual items worn are correctly added/removed). I guess that's a whole separate new bug though since apparently it has been happening for at least a week or two. The permissions-UUID side of things appears to be fixed.
(0029473)
danbanner (manager)
2015-09-11 16:02

Thanks Diva! setting full perm works correctly now
(0034602)
BillBlight (developer)
2019-02-06 11:50

Marked as Resolved but never closed, can be reopened if needed.

- Issue History
Date Modified Username Field Change
2015-09-07 15:39 danbanner New Issue
2015-09-07 17:28 danbanner Note Added: 0029450
2015-09-07 17:31 danbanner Steps to Reproduce Updated View Revisions
2015-09-07 17:38 Jim Jackson Note Added: 0029451
2015-09-07 20:55 LaniGlobal Note Added: 0029457
2015-09-09 20:17 Diva Note Added: 0029461
2015-09-10 08:24 Mata Hari Note Added: 0029462
2015-09-10 08:42 Mata Hari Note Added: 0029463
2015-09-10 08:43 Mata Hari Note Edited: 0029463 View Revisions
2015-09-10 08:44 Mata Hari Note Edited: 0029463 View Revisions
2015-09-10 08:55 Mata Hari Note Edited: 0029463 View Revisions
2015-09-10 17:06 danbanner Steps to Reproduce Updated View Revisions
2015-09-11 07:28 UbitUmarov Note Added: 0029466
2015-09-11 07:37 Diva Note Added: 0029467
2015-09-11 08:38 Diva Note Added: 0029468
2015-09-11 09:50 Diva Note Added: 0029469
2015-09-11 11:06 Mata Hari Note Added: 0029470
2015-09-11 11:08 Diva Note Added: 0029471
2015-09-11 11:26 Mata Hari Note Added: 0029472
2015-09-11 16:02 danbanner Note Added: 0029473
2015-09-11 16:02 danbanner Status new => resolved
2015-09-11 16:02 danbanner Fixed in Version => master (dev code)
2015-09-11 16:02 danbanner Resolution open => fixed
2015-09-11 16:02 danbanner Assigned To => danbanner
2019-02-06 11:50 BillBlight Note Added: 0034602
2019-02-06 11:50 BillBlight Status resolved => closed


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker