|
|
|
Any idea which simulator and sim version you got the repro on, Fake? I've tried 5 sims now and the test is still not repro'ing the result you got.
I tried for a while to repro this on a laggy sim, and failed.
To be clear – what is the output you see when this happens? You get a "The value of x is now 2", but upon reattachment it says "The current value of x is 1"? Or something else? You say it occurs during rolling restarts. Which sims are you on when this is happening? Is this a sim that has very recently been restarted, or on any general sim during a rolling restart? How consistent is it during rolling restarts? I omitted the expected and erroneous result, so yes you are correct that the value "goes back" to the initial cached value. i.e. you have x=5 you wear the object, click a few times to get x=8. On detach rewear you'd expect the value of x=8, but the erroneous (and really difficult to repro) value would be x=5.
I have had sporadic reports of this over the last few months, unfortunately the reports are rather incomplete as they are essentially "hearsay" - the reason I suspect a link to rolling restarts is that these reports appear to come to me at a time when rolling restarts/sim updates are in progress. I am currently working to find an exact timestamp/sim location for an instance of this erroneous behaviour so that it's possible for you to examine sim/asset/inventory logs to hopefully nail this down. Perhaps Fake can supply such info when he gets back online? more informations below
I could repro on following two server versions. What the object said are below. I tried on 1.24.9 server. I TPed to 1.24.10 server then. I didn't know about this behavior until I noticed this jira. Thanks Fake for the extra info.
ah ok on aditi Wanderton (Second Life Beta Server 1.24.10.106174), i now see this happening also... The effect appears whether you have the script compiled to LSO or Mono (so that makes no difference). Upgraded to "critical", as this seems to be a common rather than rare repro.
I wrote "I didn't know....", but it's my lapse.
I've experienced several times that the attachment's contents rolled back when I re-wore that quickly. I think the global variables do not roll back but just the script rolls back. The first time i heard anything like this was in sim version 1.21 back in feb, but that was owing to sim crash for such a "rollback" to happen. This specific current bug appears to have been introduced in 1.24 version as i heard no reports of this until perhaps november.
I suspect it's a caching issue with the attachment - so the whole object (and the script it contains) is being reloaded from a stale version. I just noticed a forum post that looks highly related..:
http://forums.secondlife.com/showthread.php?t=299650 This does seem to support the theory about this being a stale cached version of the entire object (as Fake points out) which is being reloaded and also that it specifically seems to affect attachments. edited to make the title more accurate and reflect that it's not so hard to repro after all...
I have noticed that this happens more frequently, if you right click the worn object in inventory and select "Detach from yourself" (or double click in Henri's "Cool Viewer", I can't remember if the official viewer unwears on double-click).
if you right-click the attachment on your avatar and select "Detach" it seems that the "discard changes" problem happens less frequently. I have also noticed this problem if I should crash during teleport, worn atrtachments revert to their last archived states. It's not just script memory that's affected. Prim shapes, colours, textures, inventory contents, more-recently-compiled-versions of scripts, notecards... the object can discard ALL CHANGES since last worn. When building / working-on attachments and altering scripts within them, etc.. I usually will go through a ritual of right-click attachment, drop to ground, right click object, take copy, right click object, take, then wear object from inventory, and the changes seem to have "stuck". The llSetObjectName / llSetObjectDesc sub-issue is longstanding, and goes back at least 2 years. Some people would describe it as "intended behviour" based on it's longstanding nature, but it sure isn't expected behaviour. I'm wondering if there hasn't been at least a partial resolution to this issue as I am not able to replicate this any more? It did seem to become reasonably easy to replicate inworld just before christmas and then has become extremely difficult to replicate shortly after the new year. I have also noticed that for a while rewearing attachments was much quicker and now it can take a bit longer for an attachment to attach – would this explain it? Was sync code removed to speed up attachment and thus causing this far more serious issue as a side-effect?
Any Linden comment on this would be greatly appreciated! I still could repro this issue as same as before.
This is easy to reproduce if you know how to identify the situation in which it can happen.
Press ctrl+shift+1 to get the stats of the sim and client. You will notice 'pending downloads' and 'pending uploads' being listed. Pending downloads are the asset requests made in direction to the sim, from the asset servers, i.e. pending objects to be rezzed or attached. Pending uploads shows the assets that are still being sent from the sim to the asset servers for storage, be it by delete, take to inventory, or detach. A simple way to reproduce this is to wait for a sim to have slight connectivity delay. When the upload queue reaches 10 or so and does not quickly decrease, simply detach and immediately reattach an object, before its upload is done. The sim will get the old version from the asset servers, as the new one hasn't been sent to the asset dbby the sim yet, and thus it will also save the old version on a subsequent detach. The same goes for taking an object into inventory and rezzing it again immediately before the upload is done. After sporadic and limited exposure which started mid-year 2008, the incidence of this has increased enormously during the period mid-Dec/mid-Jan, but now is all over the grid.
The TMC Store Card System which has been free of issues for OVER TWO YEARS is now compromised. This is now critical. It affects ALL in-world store card systems. This will destroy my reputation and business in-world. My customers think it is my bug – but it is not a bug in the TMC system. It is a bug in SECOND LIFE. I am really concerned - this issue has been open since December 24th? Why hasn't this been fixed or addressed yet? The majority of prominent merchants use the TMC store card system. Please respond ty
This issue needs to be addressed and looked into asap. There is many large business in second life that use the current system that are waiting answers on what this bug is what causing it and with it being open since the 24th of December and no one addressing it yet I would be wondering what going on..
This is a HUGE concern for many store owners using this system. I have this system working perfectly fine for a year and a half now, this issue needs URGENT attention!!
This needs to be addressed IMMEDIATELY as a priority. I cant believe this issue has been up since December and nothing has been done. Creators could be getting ripped off left and right. SUPPORT the people that bring business and money to SL, LINDENS. Are you listening?
hi.. I ve tried a card from your system .. Escort.. apparently works correctly.. in my main store... (I am lil bit concerned tho)... a solution would be really great for us.. and for ur reputation of course
This needs to be dealt with immediately! I use this system too, and the impact of this issue could be huge!! We have enough problems and stress with thieft.. Now this??? Please get this fixed ASAP!
I had no idea this issue existed until today. I cannot believe that this has been going on since Dec. 24th. Please Lindens make this one of your HIGHEST priorities; it needs to be addressed ASAP. Immediate action should be taken. Most major store owners are in limbo until you do. Support the ones that make Second Life what it is.
I have just begun using the TMC System in my store. It is very important that this be fixed! Please fix this ASAP!
I have recently purchased the TMC storecard system and am now concerned that my business has been compromised. Please address this issue as a matter of urgency, Linden Labs.
For such a critical problem, I am appalled at the apparent disregard LL has shown towards resolving this issue. It appears that instead of providing a solution, you have exacerbated the issue over the last two months.
This should be at the top of your 'to-do' list. I am pretty sure that this is a side-effect of the "fix" for "cant' wear attachments" (VWR-3015 et al.), that was introduced last year to speed up wearing of attachments on laggy/network compromised sims. While inconvenient, that bug is far less serious than this compromise. I request that that "load cached" code be REMOVED until a proper solution has been found that DOES NOT COMPROMISE the integrity of scripted attachments.
Note that this issue is massively exacerbated during rolling restarts, on very lagged sims, and at times of network compromise. Except for the fact that VWR-3015 was never fixed.
@Workingonit Linden
I hope you are, this is causing serious waves In-world and is a major concern to all of the shops using Card Systems. Although I havent been able to reproduce these results with my own card system (as yet), im very uncomfortable with it being displayed on an open-jira for all to see- as it becomes more well-known In-World the urgency on finding a fix is even more urgent. Stores are shutting down their card systems as we speak- a comment from a Linden on the case here would be greatly appreciated. @Harleen – Yes, that issue was "fixed" but the fix was not recorded/assigned against VWR-3015. Please don't use this issue as a discussion board for your own purposes. This is an extremely damaging issue and should be dealt with carefully and fully..
I have to agree with Nena Janus. This affects some very big merchants that use the gift card system, some with over 10,000 update group members. I alone have over 5000 and though I haven't reproduced the issue yet am very worried over the issue and don't like having such a vulnerability exposed to the public for overlong like this has been. How long do we wait before it's exploited? PLEASE fix ASAP
This is a huge security hole that potentially has realworld financial consequences for residents who run SL businesses using ANY kind of giftcard system - glad I noticed it before I purchased a giftcard system for my business!
@Escort - I do not see how my comment was a discussion board for my own purposes. If the fix was never recorded against VWR-3015 how would I know it was fixed. I have never said or inferred this was not an extremely damaging issue.
This issue has to be fixed. Neglecting it is a very thing for commerce in Second Life.
Please fix this LL! Immediately!
I would feel a lot better if we could get some Linden acknowledgment of this issue now that the issue is widespread and well known (and has been exploited!)
Out of curiosity, is there a way for users to actively trigger the conditions in which this bug surfaces, or do they just wait until sim performance dips? If it can be somehow triggered by a single or group of avs rather than people opportunistically jumping into a sim when performance dips, this is pretty serious. Removing scripts from several hundred vendor objects is going to be a pain. I know that scripts can be disabled on land that you manage, but often store owners have satellite locations in which they do not have parcel mod rights. Please address this bug quickly, or just say "Yes we know, we're investigating!" I am using this system in my store and I cannot believe that Linden Labs knows of the issue and it has been repoduced by merchants to PROVE it is an issue and it has not been taking care of . People have lost and are LOSING money because of your blatent disregard for this issue. I, as well as many other merchants and citizens of SL, will be very dissapointed if this issue is not resolved.
I could repro this issue but only when wearing/detaching/reattaching the attachment happens quickly and only in certain (few?) instances.
For example, yesterday I've tried to repro in 7-8 different sims. The attachment took relatively long to attach (1-3 seconds) and I couldn't repro the issue. Today, I've tried it again on the same sims, the attachment attaches/detaches almost instantly and roughly in 1 out of 5 times I could repro it. This issue in fact got the same root as VWR-7039: the failure to save the state (color, texture, attachment offsets, script states, contents) of an attachment does occur every time you crash and whenever you detach and reattach the object too fast (i.e. without waiting enough time for the changes to be uploaded back into the asset servers: a delay which will vary with the sim and grid loads).
Please see my comment at the bottom of VWR-7039 for a reliable repro. @Henri – yes I believe these issues have the same root cause – I'm pretty sure it's the way the server side deals with things rather than the viewer-side though - for reasons noted above (note esp. that sim uploads pending is a good indicator of trouble).
Hmmms. Well I have known for a long time that if you detach an object by wearing a different one, often nothing gets saved. Sometimes does, sometimes not.
It's a buggy thing that annoys me while making attachments of all kinds. So I'd guess that is what is happening here. Really old bug. I suspect the only way to be sure that this is not getting compromised is to have some kind of communication to an offsite database, and not rely on scripts in the card. @Hypatia – that bug was actually different from the current one and didn't affect gift cards. The issue with the offsite database idea is this: how do you track gifted card value? If you think it through, you'll see that all the same issues apply even when using offsite storage of the value and thus this is not an option that will allow the creation of a store/gift card system in SL. It IS possible to use that for debit/credit card applications, but not for store/gift cards. Thus this bug remains a showstopper for me, other card makers and for hundreds of merchants.
'Hmmms. Well I have known for a long time that if you detach an object by wearing a different one, nothing gets saved. It's a buggy thing that annoys me while making attachments of all kinds. '
Not yes, its hit and miss. I see its working correctly at the moment, but it doesn't always.
Which is why I am usually pretty careful to detach the object and not simply wear another on the same attach point. I have lost changes this way, its really annoying. Escort - its called "don't trust the client" an old old tenet of programming. Relying on the gift card to store values is asking for misery. We do have communications in SL and the ability to use databases on a website is well documented, its probably a good idea to use them especially when dealing with money. It's quite obvious to me that you haven't fully thought this through Hypatia – if you do you will see that a gift card cannot be implemented any more securely by using an offworld database, and it will just increase merchant dependence on a(nother) third party system being available. Also, cards are not exactly "clients" as the script runs on the simulator. It is trivial to see that a credit/debit card can be implemented in the way you suggest, but the same does not apply to user transferrable cards – the whole point of a gift card. You can enforce better by forcing the user to rez the card object but then you are asking merchants to have both rez and scripts enabled in their store – this represents an unacceptable security risk. If you would like to discuss the ins and outs of gift card systems please contact me in-world and I shall be most happy to discuss the balance of merchant/user requirement. Finally I should say that this system has run for two years without issue prior to this rash of incidents relating to this bug.
the workflow could go like this
rez gift card gift card checks database for balance - gets balance from site (this is not stored permanently in the card) Customer uses card. Gift card asks to vendor to buy. Vendor checks balance, sends debit. Deliver product once checked. Offfsite database debits customer account, storing value for next rez. Gift card asks for balance again from site, updates its balance from site after purchase. You might even be able to do this inworld. The main thing is that the gift card has to be assumed that someone will try to tamper with it in some way. It needs a way to check its values to see if they are legitimate. You could probably use something of a blend of transaction histories and the like. It's worth pursuing IMO. I never trusted the smart cards IRL for the same reasons - anything in the hands of a consumer is subject to possible tampering or theft. And LSL is surely not nearly as secure as the sophisticated tech involved in those - and they still get cracked. Escort, I've been a retail manager RL and I am also a merchant in SL. So please save the talking down for someone else. I am well aware of merchant issues due to being one. You are confusing not agreeing with you with my not being experienced in these issues, big mistake.
You want a solution to something that may not be long term possible for you to obtain. And you are misrepresenting about how no script land works - if group is checked for scripts, you can have your scripts work that are set to the group. Also if scripts are off - How else are the customers going to use the gift card?? You will have script failures. Yes scripts can continue to run in attachments when entering from another sim, but they don't run completely. If scripts are off completely, your gift cards in the hand of a customer aren't likely to work correctly. I never believed turning off scripts did much except annoy people in stores, making their AOs break down and the like. I generally refuse to stay long in such shops. Most theft is done via client mods or other third party applications that run completely outside SL, which no script land can't protect against. Turning build off is a better bet, and that is still not bulletproof. Also the account can be keyed to the card account and not to the owner. Not really difficult - its how some debit cards work. That solves your transfer problems. The usual state of affairs is to just sit on this Jira continuing to complain about it while doing nothing (seems to be the usual way for some people - scream at LL to do something about insecure designs when one can cook up better alternatives.) It's always going to be a war with cheaters, there's not a lot one can do except do something about it to make it a little harder for them. You need to balance this with your customers needs - you can in fact make things so annoying for your customers that they won't buy from you. LL might fix this bug - or maybe they wont be able to completely. Seems like latency and crashes are part of the problem. That's always going to be a problem... shrugs This bug isn't even new seems like, you just didn't notice it was a problem till recently. I always knew attachments can roll back to an earlier state for any number of reasons, its happened enough times to me :/ One sim I have a store in, rolled back an hour due to a sim crash (reverted to last stored state) a few days ago and lost a ton of changes all over my shop, mostly likely due to the Mono bug (squatter had rezzed a sim killer on a different part of the sim). It sucks, to be sure! All my script changes were rolled back, everything. Thank goodness it was all my stuff - I just lost an hour work. But it could just as easily been someone setting out a bunch of nocopy items, and they'd have been gone. It's quite possible a store card might have lost whatever had been transacted as well. Third party: Most people can't even write a script, so everything is third party to them. And if someone wanted to badly enough - anything like this could be implemented open source and leave it up to the merchant to install it all. Like any number of merchant systems, blogs, etc. You know, like real life web merchants do. You can't treat this like a game when it suits you. If you are making money at this, it's up to you to sort out the security, security is a problem on the internet and in retail everywhere and forever, and I can see that it's unacceptably insecure to use gift cards in this implementation. Which is why I don't use them. I don't even trust smart cards RL (one good example - http://www.virginia.edu/uvatoday/newsRelease.php?id=4321 anyway, back to RL. Even leaving aside the issue of people trying to cheat with it, I'm not sure that it's ever wise to trust the system itself without some form of backup. This is especially true when it comes to script variables, as it is well known that these are transient and can be subject to being reset or otherwise having random reverts pop up. Many scripters have experienced changes made to scripts in attached objects getting reverted, and in fact most of the scripters I know either edit scripts in inventory, or rez the attachment on the ground to edit scripts for just this reason. If changes to the script code itself can occur like this, then obviously changes in the script variables can as well.
All it takes is one blip for a script variable to get changed, whether that's the script being reset, a sim crash, a client crash, being detached too quickly, or actual intentional hacking. As such, it makes very little sense to have a single-point failure in such a system where money is involved. There need to be backups implemented in some fashion. Hopefully LL will find a way to deal with this bug, simply because it's an annoyance if you're scripting an attachment and want to be able to make edits while testing it. Also, some games have HUDs or other attachments that keep score, and obviously it would suck to lose points in a game due to this bug, and such a thing is trivial enough that it's probably not worth keeping an external database. However, it is also possible that there may be no perfect fix for this, and script variables are always going to be vulnerable to problems like this. Anything involving money must have a backup and not be vulnerable to a single failure. What do the last 3 comments have to do with SVC-3579?? – this is not a forum. @hypatia - your suggested solution cannot provide a gifting function.You have not thought the use cases through.@jahar - some of what you say is true, and some is not. Can we have these discussions in-world or in "scripting tips".
This ticket is to clarify/vote for a recent bug introduced into the SL platform that *should and can be fixed*. Discussions about good scripting practices don't solve the problem and discussions about the pros and cons of different card systems are not leading to the goal of making SL more reliable because this bug can influence all kind of scripts not only cards.
Any external databases can only be workarounds with many side effects to a problem that comes from within SL and should be solved within SL. If I can not rely anymore on a value that is stored in a script scripting becomes absurd. I would like to point out that it is not immediately clear, at this moment, that this problem can be fixed, and it also appears that this may not be a new bug at all. Scripters have known for a while, well over a year now, that if you edit scripts in an attached object, the script changes can get reverted when you detach it. It is very likely that this particular problem that you are experiencing is related to this.
It appears to be directly related to the manner in which changes made to an attachment get transmitted to that item's file in the asset cluster. While LL may be able to streamline this process, and perhaps make this bug less likely to occur, it is entirely possible that there will be no long-term solution. In fact, as a general rule, scripts can randomly encounter errors and get completely fouled up. This is why people who make scripted attachments (such as myself) almost always include a reset command, and make the objects copyable so that if the scripts get so badly borked that even a complete reset fails to fix it, another copy can be pulled from inventory. However, obviously that solution does not work for some of the specific cases mentioned here, such as gift cards or objects that are keeping score in a game. Obviously for these cases, the best case scenario would be for LL to fix this bug. However, in the event that this is not possible, I do think that it might be useful to discuss other options for how creators can implement these functions. Obviously workarounds are not something that anyone wants. However, sometimes workarounds are necessary both as a stopgap solution while the problem is being fixed (and don't kid yourselves, it's likely that even if someone were to find the bug today, this would likely not be implemented until the 1.27 rollout at the earliest), or as an actual solution in and of itself if the problem turns out to be unfixable or only partially fixable. Should the problem turn out to be only partially fixable, then it most certainly would be important to discuss which cases are most affected by this bug, as well as which cases can make do with a workaround and which can't. As for being able to rely on a value that is stored in a script as a variable: A global variable that is hardcoded and does not change at all in any script event is probably safe. However, if you have functions that are changing a variable's value in the script, there is always the possibility that this value can be reset or that a change might not be recorded. There are many workarounds to this problem and they are used quite often, such as storing values in the object description, or sending information to an offworld database or sending the information to a central server in-world, or some combination of the above. Until and unless scripts gain the ability to directly write to notecards, any data stored as a variable in a script should be considered just that: a variable. Look, I would hope that there does turn out to be a way to fix this bug, but even if this specific problem of scripts in attachments not having changes stored on detach were fixed, and fixed perfectly, it still would not change the fact that data stored in a script is inherently unstable. One-time bugs will still pop up, variables will still change randomly, or changes will not be registered for a variety of reasons that probably cannot be fixed. This is important to keep in mind, along with the very real fact that any potential solution is not going to be implemented immediately. This issue came up in public bug triage on Monday. The problem's actually been in SL from the day attachments appeared.
The issue looked stalled internally, so we moved it to the proper triage pile for attention and detailed a suggested fix. Thanks for the comments and suggestions above - hopefully a fix will be in within a couple versions. Thanks Soft but am I to undestand that within a couple of versions means this will not be fixed for a couple of more viewer releases? No offense personally but LL used to be much better at address issues quickly when they involved money. I hope I am misunderstanding and confused because viewer releases are kinda few and far between (not that that is a bad thing per se).
I believe that Soft is referring to Server versions. The iteration cycle for that can be as short as a week. For sure the underlying lack of transactions in SL does mean that the problem has "always been there" but it's been extremely rare until late last year. The critical nature of this means that this issue is now extremely common.
in my opinion, protection against replay attacks would be a basic level of security needed in a gift card system. Half the reason this issue is a problem is negligence on the system creators part.
...except this doesn't result in replay attacks... one thing does change at each rez and that is the card object UUID/Key
really? I thought attachments remained with the same UUID, cause they aren't being copied and kinda don't even leave the inventory and such...
The iteration cycle for server versions can actually be quite long. Especially since you want to have adequate QA testing to ensure that fixes don't screw with anything else (such as coding in attach events, in this example). Obviously Soft would be the person to give the final numbers on this, but in this case "a few versions" likely means 1.27 at the earliest, maybe 1.28....this means likely a few months. 1.24 was released, I believe, in August or September, and 1.25 was released in January.
Yes, this involves money, but not directly. If this were a bug that was directly related to SL's monetary system (say, a bug with PERMISSION_DEBIT or the money() event), then yes, it would probably be fixed within a week, but it would also likely have been moved to an SEC ticket. While I appreciate that this does affect a large number of merchants, it is also a bug that has been well known to many people, and there do exist stopgap methods for dealing with the problem until it is fixed. For situations in which money is involved, Eata is absolutely correct, there are serious issues of negligence on behalf of some creators here, and several people have made attempts to be helpful and leave comments with suggestions for workarounds until this bug is fixed. A quick thing with the UUID issue: This isn't directly related to this bug at all. UUIDs of copyable objects will change with each rez....on the other hand, I do believe that the UUID of no-copy objects remains the same. In any event, none of that is related to the script itself or the script variables, which are the main issue here. the title has been changed to mean the whole attachment and not just the variables in the scripts in it
and what about the UUID of attachments, do they really change on each attach even though they're not really being copied? btw, is this really supposed to be marked as "Showstopper" or should it be "Critical" isntead?
@TigroSpottystripes Katsu
Yes, the UUID of an attached object changes each time it rezzes, i.e. each time you log in with the attachment already on, or each time you attach the object from your inventory. Try this script to see by yourself: Just like the in-sim objects, the attachments are "deserialized" from the asset server and rezzed in the simulator server. They are simply linked to your avatar (or to your HUD view) instead of having a fixed position in the simulator. As for flagging this issue as a show-stopper, it's rather exaggerated IMHO, since this issue existed since attachments existed... Are you telling SL has been unusable all this time ?... ;-P "and there do exist stopgap methods for dealing with the problem until it is fixed". I am most intrigued to hear of one that would work with the use case - John buys a card, gifts it to Jane, Jane goes shopping in X store. i.e. the core use case of a gift card. The store is necessarily a no rez parcel.
"it is also a bug that has been well known to many people" – the issue has been the level of exposure - something did change to turn this effect from "rare" to "common". also if you knew of this bug then why did YOU not report it? "showstopper" - it was not me that made that change. I originally marked this issue major as you'll see from the OP). "versions" - i have never seen a major version change, minor versions (1.x) can take a while, patch versions (1.x.x) do have iteration cycles as short as a week. Maybe Soft can clarify which level the "couple of versions" is being referred to. "negligence" – i dispute that strongly. Don't see why it wouldn't be a replay attack. The flaw that replay attacks use is the fact that whilst the data might be secret there may be some way to send it again, usually by watching what something does and then repeating it yourself. Whoever made these gift card systems just assumed that was impossible due to their communication method. Possibly they were correct about that but they failed to account for the fact people could exploit the system to make a legitimate card transmit multiple times.
@ eata – define precisely what would be meant by "the same card" then the fact that this is not "replay" becomes very obvious.
This problem is frustrating, but could it involve a legitimate design tradeoff rather than a simple "bug"? Perhaps more should be done to inform scripters that attachment state is just not the right place to store critical accounting info. Escort: I sympathize with your situation, but why try to base an accounting system on mechanisms lacking appropriate guarantees? Someone other than LL is making a mistake here. Even if they "fix" this, you shouldn't count on it as 100% reliable so another method or check would still be beneficial. @ Xoph your comment "user must request balance transfer" is actually the closest to any kind of solution so far offered. It's workable but the problem is that the use case for that is actually harder than just giving L$ directly via Pay Avatar.
This is basically the same problem as VWR-70, is just seems to be easier to make it happen now.
Dear Linden Lab,
Is this serious issue going to remain permanently in "triage" (which btw simply means "prioritizing" i.e. zero actual action)? Will there be some update and even better a fix? Is ignoring the wishes of paying (many premium) customers really an effective way to deal with SL's most serious issues as a platform? Will the situation regarding serious bugs improve or can we expect the platform to continue to get worse/less reliable? My questions will get increasingly generalized and vocal as time progresses as I have personally lost patience. Escort, Soft stated that this issue was being looked at, and that LL devs were searching for appropriate solutions. He also stated that a solution might be implemented "within a couple of versions."
At the time that Soft wrote that comment, SL was running server version 1.25. LL has just released server version 1.26, and they are in the process of rolling out some minor tweaks to that server code as I write this. Generally, 1.x.x updates are to fix bugs that are directly related to that server version's rollout. The sort of fix requested here, which would likely involve database-asset cluster communication (and coordination with VM script states) would almost certainly be the sort of fix that must be implemented in a 1.x update, not the sort of thing that can be squeezed into a 1.x.x update. I mentioned earlier that 1.27 was likely to be the earliest that you might see this update. At the moment, my guess is that 1.27 is currently undergoing initial QA testing on LL's private servers (although please note that this is only a guess based upon previous development timelines). Thus, it is quite possible that a fix for this bug will not be in 1.27, but might have to wait for 1.28. My guess on a timeline for 1.27 would be sometime in August, and 1.28 would likely be sometime late fall of 2009. However, I am most definitely NOT an employee of Linden Lab and I have absolutely no actual knowledge of their projected development timeline. This is just my unofficial guess based upon past experience. What I am trying to say is that I thin that you are being a bit impatient here. This issue will take time to fix. Serious bugs have taken several server iterations before a fix has been implemented in the past ( This is why several people have tried to be helpful and offer advice on workarounds and stopgap solutions. Many of us have been in this situation before, and it can be frustrating. And one final word of advice: "My questions will get increasingly generalized and vocal as time progresses as I have personally lost patience." This is a Very Bad idea. Helpful comments about observed behavior/reproduction, and polite requests for progress updates are well and good, but this sort of behavior would most definitely be unacceptable. Antagonizing the people whose help you require is not going to get you any closer to a solution, and will very likely make those people who are no doubt working very hard to find a solution much less interested in doing so. "which would likely involve database-asset cluster communication (and coordination with VM script states) "
...or simply disabling a cache timeout/reload of the object from a cached copy... which would be a TRIVIAL fix to achieve and would work. ...has it entered your consciousness that this doesn't happen with rezzed objects only attachments, and have you asked yourself why it's possible to achieve this with rezzed objects and not also attachments, and also that the system ran for TWO years before some other "fix" caused this as a side-effect last year. ...it should be patched... NOW. ...and since we are apparently giving advice to each other here... allow me to introduce the following wisdom...
"When debugging, novices insert corrective code; experts remove defective code." ...quoting Richard Pattis http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Beta_Server/1.27
That's three versions and still no sign of closure. /esc Almost another another 60 days in the can since the last comment... and this is STILL a huge issue.
Observations: This is more likely to happen when you remove several attachments together. (i.e. right click a folder and 'Take Off Items'). When this happens, you can see reversions back through several of your own revisions. For me, this is mostly a scripting update issue, but I have made serveral successedul changes to an object (detached and re-attached), and then had a reversion back to where I first started working. I have made changes, completed work, detached, reattached to confirm the update was successful, then COPIED the item and worn the copy and found that the COPY has reverted... but the original has NOT. Furthermore, I have even had a revised successful copy of a copy revert to the original version of the original object on a later login. All I can say about that last occurance is "How the in heck did that even happen?!" I run into the more common occurances of this ALL THE TIME as a CC who specializes in scripted attachments. It's ridiculous to have to repeatedly make copies of scripts as a backup before taking an object off just to be sure I don't lose hours, and hours of work. But the problems I suffer from this are negligable compared to the kind of impact this is having on scripts that rely on script memory for financial data storage. It IS a showstopper for them. Escort's TMC system is very widespread these days, and his is not the only gift card system out there. This really needs some attention, no matter how long the issue has been around. All that proves is that this is an issue that exists on a low level... and the cause needs to be identified and fixed. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Showstopper
Attachments reloaded from stale versions on rewear (was: stale globals on attachment rewear)
This issue would be repro at a high probability when you re-attach the object ASAP after you detach it.