|Anonymous | Login | Signup for a new account||2019-01-21 15:12 PST|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002879||opensim||[REGION] OpenSim Core||public||2008-12-20 03:53||2012-02-10 13:40|
|Target Version||Fixed in Version||master (dev code)|
|Summary||0002879: Covenant fails because of garbadeg notecard (database inconsistency ?)|
|Description||After update to 7804 after i while i did look into land - there was no covenant any more.|
on the estate managemet tools it say "Problem importing estate covenant: Covenant file format error."
as a estate manager i tried to add the covenant again by drag and drop, got the question wether to change - but nothing did happen.
used Hippo 0.4
|Tags||No tags attached.|
|Git Revision or version number|
|Run Mode||Grid (Multiple Regions per Sim)|
|Environment||.NET / Windows64|
|Attached Files|| sharkland covenant.txt [^] (817 bytes) 2008-12-20 04:04 [Show Content]
081226 sharkland covenant.txt [^] (3,168 bytes) 2008-12-26 12:49 [Show Content]
081226 covenant garbage.txt [^] (817 bytes) 2008-12-26 12:49 [Show Content]
covenant-AF.txt [^] (815 bytes) 2009-12-15 16:46 [Show Content]
covenant-AF-OK.txt [^] (4,871 bytes) 2009-12-15 16:49 [Show Content]
0001-Fix-Covenant-view-fails-after-updates-or-cache-clean.patch [^] (1,664 bytes) 2012-02-10 12:20 [Show Content]
|could you attach the covenant that causes the problem?|
@Teravus: will do shortly
My "Estate Owner" Tag on the Land --> Covenant Tab is saying "(none)
The Table EstateSettings has a "00000000-0000-0000-0000-000000000000" for all Estate Owners...
does this affect something ?
is it intended ?
--> i did change the region owner (in /Regions *.xml did change First/Last/Password) to dig into the teleport/login problems maybe related to beeing the owner...
see the attached file...
i have no further question - that is something i could not accept, either.
BUT: this notecard did conatin a nice small bilingual covenant just 3 days ago...
what did happen ? inconsitency in asset/inventory-server it seems
I have experienced the same a long time ago (see 0002208). That bug even destroyed my convenant notecard, that afterwards looked similar to the attached file.
But since 7797 I did not experience that problem anymore - at least till now. That's why I have closed 0002208. But it looks like that this bug still exists.
|I went to look at this and noticed that the attached covenant is not valid. I'm not going to be able to reproduce the issue with out a valid repro covenant.|
just to clarify:
- i hdad a covenant for some days - still got the notecard in inventory
- opened the land dialogue and the covenant was gone, error as above
- did open estate tools and di drag the covenant again, did not work
- did put this ticket
- you asked for the notecard
--> i noticed that the former proper content was now garbage !!
- i did copy the content from viewer to a textfile an uploaded
--> so, i guess the central server crunched the notecard
--> as well i spoke today to the owner of Port Edward, same effect
So, was this just missunderstanding - or do i need to upload the notecard with garbage some other way ??
|please upload the notecard as it was before it got mangled. Thanks|
where do i get the original ?
i did put the text togehter in the client...
for the next round i have a RL backup...
|Without that, I don't really have any way to reproduce it. So, this bug should be closed.|
well, i will search inworld for other reagions and possibbly someone as a backup of the note outside osgrid..
keep it open till xmas
ok - i got severeal people with that error.
but non seems to have save the covenant as a backup outside the grid.
so, error seems to be there - but canÂ´t help to get a orginal covenant.
Please describe steps for reproduction of the problem or the developers will be unable to reproduce it. If this involves upgrading from one revision to the next, include that in your steps. Something like:
1) Install rXXXX.
2) Run it in grid/standalone/... mode with the attached OpenSim.ini
3) Create convenant with the following text "Hello this is a test"
4) Upgrade to rYYYY in the following manner ...
I will allway try to describe as precise as posible.
But i canÂ´t say more as in the original
- did put estate covenant in place (dragÂ´nÂ´drop as region owner)
- was in place for some dayes
- did do update to 7804 (wich can be related, but donÂ´t need to)
- after a while i discovered the error
- talked to ohter people, who had the same effect
i do make plenty updates as you know - i donÂ´t check stuff like the covenant all time... :-)
BUT: today i got the error again, and did make a backup in RL.
Text in covenant: "Problem importing estate covenant: Covenant file format error."
see attached files from today for originl and crashed content.
I am experiencing the same problem on my land again.
Since I have installed the new covenants I did not do an update of opensim, so this definitively is some bug that destroys the content of the original notecard that has been dropped as new covenant in the estate owner window, as well as the text of the region's covenant in the about land window.
Interesting is, that I still see the correct text because it seems to be in my viewers cache, but all other ppl see an incorrect hair xml content as notecard, similar to the one attached to this report, instead of the original covenant text.
I have had this several times and will try to recreate.
The note card, in my inventory, that is attached for covenant becomes corrupted with the LLWearable text error as well.
I will track the UUID of the notecard as well as keeping a copy while attempting to recreate.
edited on: 2009-12-15 16:48
This issue is still present. Please see attached txt file 'covenant-AF.txt'
This is 100% reproducable for me on Teravus Plaza, OSgrid.
Create covenant notecard, save into inventory.
Log into Teravus Plaza, OSgrid
Open Region/Estate tools and drag the notecard over to the covenant window
I can see it fine, every time I go to view it
Other avatars can not see it, and it is replaced with 'Problem importing estate covenant: Covenant file format error.' in the About Land, Covenant tab
I can view the notecard fine in my inventory
I pass the notecard to another avatar, and they see what I have uploaded as 'covenant-AF.txt', where it seems the notecard has turned into hair.
Please note the creator UUID is not my UUID. My UUID is 9bd85667-8378-4feb-9edc-3eebff6facb9 adn the UUID of the alt i was using to test is d9af5321-d5d3-3a6d-015b-0a7f9243093a.
The UUID of the notecard is 4a99e379-731e-4a18-b6e8-28ccf89ce0c4 in both avatars inventory, but i still see the notecard correctly (I'm suspecting if i clear cache it will reveal garbage in the notecard) and also this is the correct UUID in the database.
What is particularly interesting is that all the creator ID's of the garbage notecards are all a52db6d0-e96c-4454-85e5-3523722daa25
edited on: 2009-12-15 16:53
I have also uploaded the un-mangled covenant as 'covenant-AF-OK.txt'
Version: OpenSim 0.6.9 (Dev) f046457: 2009-12-13 04:02:18 -0500
Windows 64bit .Net, MySQL.
Well, it appears this is STILL present. Seems like one of the longest-running bugs in opensim.
Wrote out a covenant 3 times now for my sandbox. Each time I check a week or so later and get the import error in covenant and the original notecard is a brief bit of garbage text, nothing else. Will experiment with this bug when I get the chance.
I have had this happen both from a simple matter of time (no upgrades or changes) and over the course of opensim upgrades.
CentOS 5.5 64-bit
Opensim 0.6.9 post-fixes 85c20e1
slow putzo (reporter)
Bug still exists in release 04-07-2011.
I've updated several Mantis reports of this.
The data I had put into my NC is the same on several of my regions which were hit with this bug after doing the update process. I do not suspect the update itself but rather the process that is exercised in doing a software update.
Imprudence 1.3.0 (Oct 7 2010 02:31:57)
Built with MSVC version 1400
You are at 2573784.7, 2556335.3, 21.7 in Treasure Bay located at cpe-173-170-147-227.tampabay.res.rr.com (18.104.22.168:9128)
OpenSim 0.7.1 Dev OSgrid 0.7.1 (Dev) abea0c7: 2011-04-07 (Unix/Mono)
Here is the trashed NC:
LLWearable version 22
|The covenant code has a 'wild hair'?. ba-dum ching|
slow putzo (reporter)
It sure does, and I have discovered a way to make it fail for me on my system 100% of the time.
If I login from my desktop and verify everything is fine, I can usually login over and over again without trashing the covenant. But if I alternate between two computers, for me my laptop and then my desk top, each time I use the different computer it trashed the covenant with this hair stuff in the NC.
If I login over and over again from the same computer occasionally it will get trashed. I think that is what some of the people have been able to force by clearing their cache. But without clearing cache but just alternating between computers it is solid as you could ever make a bug. It will happen every time to any of my regions. Just fix the covenant from one computer, then login from the other computer and it is trashed.
slow putzo (reporter)
wow, I just tried what AdelleF posted a few posts up about how to reproduce the problem and her way is even simpler. I am logged in right now from the same computer using two avatars. I fixed the covenant using my primary avatar and it looks just fine. I then brought up another instance of Imprudence and logged in with another avatar and it shows the covenant as "Problem importing estate covenant: Covenant file format error."
It is clear that the actual covenant has never really been changed by dropping the NC into the covenant window.
I also discovered that in the fix process you can't simply just drop a new fixed NC into the covenant but rather you first have to clear the covenant with the clear button and then you can drop the new NC into it and it shows it is fixed. However it is only fixed on that instance of Imprudence and not on the actual system for others to see. Unless you do the reset and leave that message there or leave the original covenant about linden labs in the covenant no one sees a "new" personal covenant you put into the covenant.
I suspect because so few people use the covenant and we really do not have many "residents" and landlords are not concerned about trying to parcel off and give/rent parcels, they don't use covenants.
I agree this is not a priority problem, but it would be nice to fix the bug so this functions properly at some point.
To say it can not be reproduces is not true. There are two ways described in this mantis that fail 100% of the time for at least two people and I am sure it will fail for others just as solid.
slow putzo (reporter)
Some additional information.
I just created a new NC to use as a covenant. But rather than use the "drop into covenant" method of making it the active covenant I edited the MySQL dababase and put the UUID into the data for that specific region.
After restarting the region I logged in and went to the region. On the avatar where I created the NC both the NC was good, and the region covenant showed the correct new text in the covenant. However for my alt avatar, who did not create the new text NC the covenant showed the error message. I then tried sending the NC to that alt. The NC looks just fine on my primary avatar, the one that created the NC. The one the alt received was trashed with the hair information. However before using the NC as a covenant, I sent it to the alt, and it looked perfect.
So it is the usage of a NC as a covenant that causes this problem, not the dropping of it into the covenant to make it the active text.
I also tried clearing the cache of both avatars, I did this more than once for each and restarted Imprudence. It did not cause the bad text to show up for the avatar that created the NC and it did not cause the NC to become good for the alt avatar.
Its as if the creating avatar keeps the good data somehow and it displayes both for the covenant and for the NC while other avatars have this trashed version of the NC so it fails to show as the covenant. If you send this NC to another avatar they get the trashed version rather than the good version.
If you never use the NC as a covenant, then all is fine and you can send the NC to another avatar and it arrives just fine and in good shape.
Something in the covenant code is trashing the copy held by OSGrid and replacing it with this "hair" information.
I have no idea why it takes a switch to another pc for the avatar that created the NC to finally get this trashed version, or why it is able to hold the original data even when the cache is cleared.
I'm out of ideas of how to pinpoint what is causing the inventory item at OSGrid being trashed when it is used as a covenant.
I suspect anyone could trash other peoples NC's by simply placing them into a region covenant and doing a login.
That would take three avatars online to test. Avatar "A" could create a NC and send it to avatar "B". Avatar "B" could then use that NC as a covenant for one of their regions. Log out and then back in, then, send the NC to Avatar "C" actually both Avatars "A" and "B" should send the same NC now to avatar "C" to see if both copies are identical, and if they are the original or a trashed version.
If it is trashed, then any NC can be trashed by anyone who has it and owns a region by using it as a covenant.
That would be an exposure for people who use NC givers. I'll try to test this possibility, but I only have two avatars so I'll try to find a willing helper to try the test.
slow putzo (reporter)
edited on: 2011-04-11 21:31
More information about this NC thing. With the help of Key Gruin and Nebandon on LBSA I was able to prove you can not trash a NC that is created by someone else by putting it into one of your regions covenants.
Maybe not being the owner of the NC protects it. The NC did get trashed for me, and it was trashed in the covenant, but if I deleted the NC from my inventory cleared my cache and logged off and back on the original NC could then be sent to me and it arrived as the original. If I did not clear my cache, the NC could be sent to me by either the owner or someone else, in the test cast Key was the owner or creator, and Neb was the "someone else" when both sent it to me what I got was trashed, but if I sent them the trashed NC they got the original good NC. Once I cleared my cache and relogged and deleted the bad nc's I was able to receive good copies of the NC from both Key and Neb.
I will work more on this aspect and try to find exactly what the conditions are to trash the NC.
I think it might be possible to have someone else be the creator and then use it for the covenant and maybe then it will finally persist without getting messed up.
slow putzo (reporter)
Last update for tonight on recreating this problem.
I have discovered how to make the problem almost go away. The problem is that once the data becomes corrupt it persists because of two cache entities. The cache on the server and the cache in the viewer.
I have set the cache time to expire on my test region to .1 so the cache is wiped every 6 minutes. If I create the covenent, I end up with corrupt data in both the server cache and the viewer cache. I then clear my viewer cache and log off. I wait for about 10 minutes to be sure the server cache is wiped, log back in and now the NC and the covenant are back to the right information.
I then logged in with my alt, but logged into LBSA. There I cleared the viewer cache and logged off. Then I logged back in with my alt but this time went to the test region.
The copy of the NC and the covenent now show correctly for my alt as well as for me.
I believe now that once the corrupt version of the NC is gone the covenent will remain correct.
The bug is that the NC gets corrupted in both the server and viewer cache and I guess how the system works it keeps replacing the item from those two cache copies rather than download a good copy from the grid inventory server.
I can see when it has to download from the grid inventory, and when it does everything gets corrected.
I think that if you set the server cache to a long time and you do corrupt the data, then it will persist almost forever.
I also think that whatever is corrupting the information is not present in every configuration which explains why some people have the problem and others do not. The actual bug only happens once when the covenant is created under some specific set of circumstances. Once corrupted, it persists until all cache are cleared at the same time.
The good thing to know is that the original information on the grid server is not affected by this problem at all.
The corrupt information is never sent to the grid server. It only exists in the local region server cache and the view cache.
In my configuration I use a single floatsum cache for all my instances on the same machine. The time to expire is set to be 48 hours, and only one instance is set to manage that time. That might explain why the viewer cache is constantly updated with the corrupt information and why that particular item persists so long on my configuration. I never wipe my cache when I do an upgrade, because that folder is outside of the instance folders. It remaines intact for all instances basically forever. I also do an IAR automatically every week, so things are constantly being referenced in the cache. I noticed that my IAR run went much smoother when I did it weekly, but when I did it monthly it almost always failed with too many timeouts waiting for things to be downloaded from the osgrid inventory server. Hence the corrupt NC was being saved in my IAR and it was being held in the cache because of the frequent reference. All these things made the failure almost perminent for me while for others they may not have ever even noticed the original corruption if they log off for a few days and they have short cache expire times.
Preliminary tests shows that estate covenants do not appear to propogate to other users, even though the right asset ID appears to be passed. This would be the first thing to address.
Also, we seem to be sending multiple sets of asset data when the estate dialog box is opened (which may or may not be justified).
Corruption might be more difficult to pin down. What is needed is a bullet point summary of the minimum reproduction steps for this.
|As an aside, it also appears that covenants are being stored in region settings rather than estate settings. I expect this will need to change at some point.|
slow putzo (reporter)
To make sure this mantis report has all of my actual findings and not my speculations I want to correct a speculation I made in my previous post. I "thought" once the cache was cleared and only good copies existed that the covenant and NC would not become corrupt again. Today I had my laptop with me at a friends house and wanted to show him OSGrid. I logged into my home region and darned if the covenant was not trashed again with the hair data along with my NC. I then set my viewer to clear cache, logged off. When I logged back on I went to LBSA rather than my home region. Now my NC was just fine because it had to load it from the OSGrid inventory server rather than my server cache had I logged back into my home region.
So something corrupted my server cache of that asset again overnight with the "hair" data.
I am really stumped.
I am going to bring up a "windows" test region. Put nothing at all on it, let it run on one of my old laptops, and see if that configuration using the light DB rather than MySQL fails.
slow putzo (reporter)
I might have discovered some worthwhile information.
While searching my server side cache for the NC asset, I discovered that it was not in the server side cache. This really confused me because when I log in and display the NC I used for the covenant, it shows the "hair" information.
Twice I cleared the viewer cache and relogged in, each time it continued to display the "hair" data and a search of my server cache yielded no asses for the NC in the server cache.
I cleared my viewer cache a third time, logged back in, but before I logged in I saw the expire time for my server cache expire and clean out almost everything that was in it. As I logged back in, I saw the cache fill up on the server and once my avatar rezzed I looked at the NC and it first had to "load" it. I saw the asset come into my server cache, and now the NC and the covenant displayed correctly.
What is odd, is why didn't the server go get the asset from the OSGrid asset server since it was not in the server cache, and the viewer cache had been cleared. Instead the bogus "hair" data display.
Because I thought maybe I had not cleared the cache correctly I did it a second time with the same results. Until the cache time to live on the server expires and clears the cache, the server does not try to reload the asset from the asset server.
Is something causing the server to think it has the asset in cache when it doesn't and what it sends is the "hair" data.
It is still a problem in last rev. 17921
drag a notecard to Covenat-Window does working.
The right uuid of this notecard is stored correctly in the sqlite3-db
The correct notecard-id is send to the viewer (but always the time 0, that is a another issue)
So far so good. But:
If the viewer has cached this id already, the viewer displays the notecard with no issue. But if i clear the cache in the viewer and clear the SIM-cache, restart the SIM and login again, the viewer seems to try fetch the asset with the NULL_KEY (00000000-0000-0000-0000-000000000000) as asset-id.
In my asset-db is the NULL_KEY stored as a hair (thats strange)
So it will display the fetched data with a parsing Error.
If I delete the NULL_KEY asset from the asset-db (in the robust-server) and clear all caches again and relogin, the Covenant-Window displays "There is no Covenant provided for this Estate."
That is a good find and will give a clue to look for.
Pixel Tomsen (manager)
..some time was needed to fix;-)
|2008-12-20 03:53||RalfHaifisch||New Issue|
|2008-12-20 03:53||RalfHaifisch||SVN Revision||=> 7804|
|2008-12-20 03:53||RalfHaifisch||Run Mode||=> Grid (Multiple Regions per Sim)|
|2008-12-20 03:53||RalfHaifisch||Physics Engine||=> ODE|
|2008-12-20 03:53||RalfHaifisch||Environment||=> .NET / Windows64|
|2008-12-20 03:53||RalfHaifisch||Mono Version||=> None|
|2008-12-20 03:55||Teravus||Note Added: 0008152|
|2008-12-20 04:01||RalfHaifisch||Note Added: 0008153|
|2008-12-20 04:04||RalfHaifisch||File Added: sharkland covenant.txt|
|2008-12-20 04:05||RalfHaifisch||Note Added: 0008154|
|2008-12-20 04:13||Teravus||Assigned To||=> Teravus|
|2008-12-20 04:13||Teravus||Priority||normal => high|
|2008-12-20 04:13||Teravus||Severity||minor => major|
|2008-12-20 04:13||Teravus||Status||new => assigned|
|2008-12-20 04:52||Snoopy||Relationship added||duplicate of 0002208|
|2008-12-20 04:56||Snoopy||Note Added: 0008160|
|2008-12-20 15:10||Teravus||Note Added: 0008191|
|2008-12-20 15:10||Teravus||Assigned To||Teravus =>|
|2008-12-20 15:10||Teravus||Status||assigned => feedback|
|2008-12-20 15:22||RalfHaifisch||Note Added: 0008199|
|2008-12-20 15:23||RalfHaifisch||Summary||Covenant fails => Covenant fails because of garbadeg notecard (database inconsistency ?)|
|2008-12-20 15:27||Teravus||Note Added: 0008203|
|2008-12-20 15:34||RalfHaifisch||Note Added: 0008206|
|2008-12-20 22:51||Teravus||Note Added: 0008233|
|2008-12-21 02:09||RalfHaifisch||Note Added: 0008238|
|2008-12-22 14:02||RalfHaifisch||Note Added: 0008328|
|2008-12-26 10:51||Diva||Note Added: 0008469|
|2008-12-26 12:49||RalfHaifisch||Note Added: 0008471|
|2008-12-26 12:49||RalfHaifisch||File Added: 081226 sharkland covenant.txt|
|2008-12-26 12:49||RalfHaifisch||File Added: 081226 covenant garbage.txt|
|2008-12-28 16:19||Snoopy||Note Added: 0008531|
|2009-03-05 16:24||zariok||Note Added: 0009850|
|2009-12-15 16:46||AdelleF||Note Added: 0014511|
|2009-12-15 16:46||AdelleF||File Added: covenant-AF.txt|
|2009-12-15 16:48||AdelleF||Note Edited: 0014511|
|2009-12-15 16:49||AdelleF||File Added: covenant-AF-OK.txt|
|2009-12-15 16:51||AdelleF||Note Added: 0014512|
|2009-12-15 16:53||AdelleF||Note Edited: 0014512|
|2010-06-21 22:07||OtakuMegane||Note Added: 0015693|
|2010-08-28 10:54||Fly-Man-||Relationship added||duplicate of 0004975|
|2011-04-08 18:23||slow putzo||Note Added: 0018224|
|2011-04-11 14:57||Teravus||Note Added: 0018245|
|2011-04-11 16:46||slow putzo||Note Added: 0018264|
|2011-04-11 17:09||slow putzo||Note Added: 0018265|
|2011-04-11 20:09||slow putzo||Note Added: 0018267|
|2011-04-11 21:28||slow putzo||Note Added: 0018268|
|2011-04-11 21:31||slow putzo||Note Edited: 0018268|
|2011-04-11 22:24||slow putzo||Note Added: 0018269|
|2011-04-12 16:29||justincc||Note Added: 0018276|
|2011-04-12 16:29||justincc||Note Added: 0018277|
|2011-04-12 17:32||slow putzo||Note Added: 0018278|
|2011-04-12 19:00||slow putzo||Note Added: 0018279|
|2012-01-28 13:22||goetz||Note Added: 0020730|
|2012-01-28 13:55||BlueWall||Note Added: 0020732|
|2012-02-10 12:20||Pixel Tomsen||File Added: 0001-Fix-Covenant-view-fails-after-updates-or-cache-clean.patch|
|2012-02-10 12:23||Pixel Tomsen||Note Added: 0020842|
|2012-02-10 12:23||Pixel Tomsen||Status||feedback => patch included|
|2012-02-10 13:39||BlueWall||Mono Version||None => 2.10|
|2012-02-10 13:39||BlueWall||Note Added: 0020847|
|2012-02-10 13:39||BlueWall||Status||patch included => resolved|
|2012-02-10 13:39||BlueWall||Fixed in Version||=> master (dev code)|
|2012-02-10 13:39||BlueWall||Resolution||open => fixed|
|2012-02-10 13:39||BlueWall||Assigned To||=> BlueWall|
|2012-02-10 13:40||BlueWall||Status||resolved => closed|
|2012-02-23 15:30||slow putzo||Relationship added||has duplicate 0005390|
|Copyright © 2000 - 2012 MantisBT Group|