Rolling Restart : server version 1.25.3 / 1.25.4

Like I said, but it looks like you overlooked it, the problem with this particular issue is that nothing was publicly announced about this *voluntary* change to the server software: why didn't it appear in the release notes ?...

How can you expect contents creator to worry about a particular issue such as this one (i.e. the reduction in the number of simultaneous animations per avatar) if you don't even make them aware of it ???

There is one keyword that LL still has much trouble to understand as its seems (even if things did improve a bit over the past year). This word is: COMMUNICATION

'nuff said.

Because it was not "overlooked", but rather part of a security issue.

Vulnerabilities are not disclosed until after they are patched.

See http://wiki.secondlife.com/wiki/Security_issues

The fact is that sometimes things break that we didn't think were going to break. That's why it's worth spot-checking random things on the beta grid. That's one of the things I'm most hoping for out of the "Second Life Beta Server" group. I forget which issue, but there was at least one that one of y'all caught this time around early in the 1.25 cycle.

In any event, I have just refreshed 1.25.3 on aditi; this includes fixes for SVC-3669 as well as fixes for the new 1.25 scripting crash bugs we're seeing in the pilot regions right now. Assuming this checks out, it is what will be deployed to agni next Tue/Wed. (The version on the "Second Life Beta Server" channel on aditi at the moment is 1.25.3.108077.)

Why was this post, which is mine, edited by Prospero Linden?

If you don't agree with something I write, then reply to it, but DON'T remove my post and replace it with some text I am not the author of !!! >:-<

-----------------
Henri Beauchamp <--- My post
Registered User

Join Date: Oct 2006
Posts: 209

Quote:
Moreover, this flaw is client side (animations are played by the viewer, not the server...), so the limit should have been implemented in the viewer instead (with a patch published for older viewers).


In fact, it was a server crash bug, so it needed a server side fix. <--- NOT my text !
_______________
Last edited by Prospero Linden : Yesterday at 07:33 PM. <<<<< !!!!!!! ?????

1.25.3 has re-introduced a issue, whereby if a touch_start event causes a state change, then that same touch will more often than not be detected in a touch_start event in the new state as well. This will break quite a lot of scripted objects - doors, etc.

https://jira.secondlife.com/browse/VWR-9023

Seems serious enough to me that it ought to be fixed before any further roll-out.

Agreed. I don't know whether there is a perfect solution to this in the case of SEC bugs, but I do think it is something that Linden Labs needs to keep on top of.

I would note, however, that the pilot roll-out *is* one way they *are* providing a way for you to become aware of these things. And the fact that they *are* responding to this by ensuring that the problem is resolved before the full roll-out indicates that they *are* attempting to keep on top of it.

So:

1. I agree, it's not fair to accuse creators of laxity in a situation like this.

2. But the final response from Linden Labs is timely and appropriate.

The beta grid is how you become aware of these things.

The pilot roll-out is a larger-scale opportunity to uncover things that don't manifest on Aditi, but do on the the larger scale of the main grid.

If you have any content more complex than a box of textures (and certainly any *scripted* content), either you should be smoke-testing on Aditi, or accept that your stuff may very well turn up broken when a new Server Release rolls.

If you chose that path, you shouldn't expect the rest of world to stop while your issue is fixed, unless the impact of it will be obviously a lot larger than the impact of the bugfixes in the newly rolled server.

Ew, that one is back? It's ugly but survivable.

Lemme go test, I have an object that was a victim of that one.
Although Prospero says it doesn't repro for him on 1.25.3

The beta grid is ANOTHER way you can become aware of things, but (a) it's hard to test out the latest versions of every product for everyone ... and updating the inventory for everyone who might be effected for each beta rollout would produce latency problems at LL (humans suffer from lag too. ), and (b) there have been many problems that don't show up on Aditi. So the pilot roll out is ANOTHER way that LL makes people aware of these things.

And, in any case, I don't know why you're complaining to me. I pointed out that he *does* have the warning he wants even if he doesn't test... the warning period just happens to be a bit shorter if you wait until the pilot, but it's still there.

Poop, VWR-9023 is reproing for me in Pooley on 1.25.3. I can give you the object, Prospero. See VWR-9023 for the script...I'm starting to think it's load-related

I just didn't want anybody thinking the pilot roll is a substitute for the beta grid. And I did say "smoke-test", not "every version of every product"; nobody has 100% test coverage unless they're doing TDD. If somebody's doing TDD on SL content I'd like to hear how they do it.

And just because I quote you doesn't mean I'm complaining to you. The warning time is indeed shorter, and the time-to-fix will be longer, too,

No, I generally use TTD instead. Especially when testing brain cells against scripts using the coffee-assisted late-night-hacking methodology.

I know the subject has moved on to the next bug, but I'd like to thank the Lindens for their timely response in handling not just my issue, but these other issues that are cropping up. I understanding that raising the animation limit from 10 to 30 was a tough choice, but doing so made my life a lot easier, and I appreciate it.

I'm also happy the release wasn't delayed because of it, so Maggie didn't have to kill me.

Gee, and I had our damage-enabled parcel all warmed up, too.

Well done: Prospero, Vektor and everybody else at Linden Labs who have been working hard keeping the new release on-track.

I'm glad this one is shaping up as a win for everybody, as far as I can see.

I forget the id number off the top of my head but I'm especially happy that LL did such a good job handling Darling Brody's (I am naming names but in a positive way) crash issue on the JIRA and that Darling actually kept a sense of humor throughout it, although unfortunately they did so before I got to have any fun trying to repro it though .

My guess is a race condition (clearing touch_start event trigger at the same time as switching state and state switched before the trigger is cleared)
Wonder what prospero found to be the cuase.

There was a fix. It got losted. And now it's coming back.

Anyone brought this up yet?

http://jira.secondlife.com/browse/SVC-3670

Create a new script. Rename it code_probe.lsl put the following in it.
<code>
default
{
state_entry()
{
integer max =llGetInventoryNumber(INVENTORY_SCRIPT);
integer i;

for (i = 0; i < max; i++)
{
string s = llGetInventoryName(INVENTORY_SCRIPT, i);
key k = llGetInventoryKey(s);

llSay(0, s+":"+(string)k);
}

llRemoveInventory(llGetScriptName());
}
}
</code>

Create an object. Drop the script into it.

On Second Life Server 1.24.10.106829 (WORKS)
Object: code_probe.lsl:9fc02372-74c3-22e1-b303-3362796c9d52

On Second Life Server 1.25.3.107941 (BROKEN)
Object: code_probe.lsl:00000000-0000-0000-0000-000000000000

Yeah, that's as intended -- you're only supposed to be able to get UUIDs for a few things (textures, notecards, I think), and 1.25 fixes that so it's right.

Prospero: why should you not be allowed to get the UUID for scripts? What is the purpose of this new restriction? What other types have now been restricted?

I'll say more once 1.25 is fully on the gird. I know you can get UUIDs for textures and notecards; I'm not sure which other ones you can get.

Eww.. Sounds like something that rhymes with security.

I've been having many problems since the server roll outs in late December and I'm hoping someone can help me.

I think my problems are caused by the switch to more services using the CAPS messaging system. I have very limited functionality with any of my avatars across all my platforms.

I'm not sure if my CAPS messages are being capped, blocked or sabotaged, but it sure is taking the wind out of my sails.

I've posted a log file of me logging in, then logging out here:
http://landtracker.co.cc/ZolenLoginSecondLife.log

A snippet of the log file that shows my inability to properly connect with the CAPS system (I think) is posted below. Any help or suggestions would be greatly appreciated.

2009-01-17T23:15:49Z INFO: addCircuitData: LLCircuit::addCircuitData for 216.82.22.49:12035
2009-01-17T23:15:49Z INFO: addRegion: Adding new region (1107:1017)
2009-01-17T23:15:49Z INFO: addRegion: Host: 216.82.22.49:12035
2009-01-17T23:15:49Z INFO: process_enable_simulator: simulator_enable() Enabling 216.82.22.49:12035 with code 580203534
2009-01-17T23:15:49Z INFO: addCircuitData: LLCircuit::addCircuitData for 8.2.34.213:13002
2009-01-17T23:15:49Z INFO: addRegion: Adding new region (1106:101
2009-01-17T23:15:49Z INFO: addRegion: Host: 8.2.34.213:13002
2009-01-17T23:15:49Z INFO: process_enable_simulator: simulator_enable() Enabling 8.2.34.213:13002 with code 580203534
2009-01-17T23:15:49Z INFO: addCircuitData: LLCircuit::addCircuitData for 216.82.19.21:12035
2009-01-17T23:15:49Z INFO: addRegion: Adding new region (1105:1017)
2009-01-17T23:15:49Z INFO: addRegion: Host: 216.82.19.21:12035
2009-01-17T23:15:50Z INFO: process_enable_simulator: simulator_enable() Enabling 216.82.19.21:12035 with code 580203534
2009-01-17T23:15:50Z INFO: addCircuitData: LLCircuit::addCircuitData for 216.82.17.36:13002
2009-01-17T23:15:50Z INFO: addRegion: Adding new region (1106:1016)
2009-01-17T23:15:50Z INFO: addRegion: Host: 216.82.17.36:13002
2009-01-17T23:15:50Z INFO: process_enable_simulator: simulator_enable() Enabling 216.82.17.36:13002 with code 580203534
2009-01-17T23:15:50Z WARNING: addRegion: LLWorld::addRegion exists, but isn't alive
2009-01-17T23:15:50Z INFO: removeRegion: Removing region 283392:260352
2009-01-17T23:15:50Z INFO: addRegion: Adding new region (1107:1017)
2009-01-17T23:15:50Z INFO: addRegion: Host: 216.82.22.49:12035
2009-01-17T23:15:50Z INFO: process_enable_simulator: simulator_enable() Enabling 216.82.22.49:12035 with code 580203534
2009-01-17T23:15:50Z WARNING: addRegion: LLWorld::addRegion exists, but isn't alive
2009-01-17T23:15:50Z INFO: removeRegion: Removing region 283136:260608
2009-01-17T23:15:50Z INFO: addRegion: Adding new region (1106:101
2009-01-17T23:15:50Z INFO: addRegion: Host: 8.2.34.213:13002
2009-01-17T23:15:50Z INFO: process_enable_simulator: simulator_enable() Enabling 8.2.34.213:13002 with code 580203534
2009-01-17T23:15:50Z WARNING: addRegion: LLWorld::addRegion exists, but isn't alive
2009-01-17T23:15:50Z INFO: removeRegion: Removing region 282880:260352
2009-01-17T23:15:50Z INFO: addRegion: Adding new region (1105:1017)
2009-01-17T23:15:50Z INFO: addRegion: Host: 216.82.19.21:12035
2009-01-17T23:15:50Z INFO: process_enable_simulator: simulator_enable() Enabling 216.82.19.21:12035 with code 580203534
2009-01-17T23:15:50Z WARNING: addRegion: LLWorld::addRegion exists, but isn't alive
2009-01-17T23:15:50Z INFO: removeRegion: Removing region 283136:260096
2009-01-17T23:15:50Z INFO: addRegion: Adding new region (1106:1016)
2009-01-17T23:15:50Z INFO: addRegion: Host: 216.82.17.36:13002
2009-01-17T23:15:50Z INFO: process_enable_simulator: simulator_enable() Enabling 216.82.17.36:13002 with code 580203534
2009-01-17T23:15:50Z INFO: LLVoiceClient:arcelChanged: not logged in yet, deferring
2009-01-17T23:15:51Z INFO: process_enable_simulator: simulator_enable() Enabling 216.82.22.49:12035 with code 580203534
2009-01-17T23:15:51Z INFO: process_enable_simulator: simulator_enable() Enabling 8.2.34.213:13002 with code 580203534
2009-01-17T23:15:51Z INFO: process_enable_simulator: simulator_enable() Enabling 216.82.19.21:12035 with code 580203534
2009-01-17T23:15:51Z INFO: process_enable_simulator: simulator_enable() Enabling 216.82.17.36:13002 with code 580203534
2009-01-17T23:15:51Z INFO: process_enable_simulator: simulator_enable() Enabling 216.82.22.49:12035 with code 580203534
2009-01-17T23:15:51Z INFO: process_enable_simulator: simulator_enable() Enabling 8.2.34.213:13002 with code 580203534
2009-01-17T23:15:51Z INFO: process_enable_simulator: simulator_enable() Enabling 216.82.19.21:12035 with code 580203534
2009-01-17T23:15:51Z INFO: process_enable_simulator: simulator_enable() Enabling 216.82.17.36:13002 with code 580203534
2009-01-17T23:15:53Z INFO: setSeedCapability: posting to seed https://sim2285.agni.lindenlab.com:12043/cap/f363060f-e3d7-7d4a-9f92-5260ef816f0e
2009-01-17T23:15:53Z INFO: setSeedCapability: posting to seed https://sim3568.agni.lindenlab.com:12043/cap/007196a1-0339-9a9d-90e4-0511d119d2e1
2009-01-17T23:15:53Z INFO: setSeedCapability: posting to seed https://sim2778.agni.lindenlab.com:12043/cap/fc37058b-ac0d-9044-4c34-188e81386505
2009-01-17T23:15:53Z INFO: setSeedCapability: posting to seed https://sim5657.agni.lindenlab.com:12043/cap/08a6f0a5-b0e7-bc88-e672-303d06844c16

ETC.....


Thank you for any help!!!

zg

Sorry! but i really feel like screaming atm.. why are server upgrades always accompanied by so many problems??

..in the last 12 hours.. i crashed more than 12 times.. each crash starting with being immobile for a while and then receiving the message.. 'you have been logged out...bla..bla..bla' ..i won't even start with so called 'lag' issues

..this is not the first time.. it appears to happen every time there are upgrades.. to the point that i want to call them downgrades

..it's NOT my pc! i've been happily running multiple viewers up to version 1.24.9 and am connected to a 50Mb cable provider..

..paying for 2 premium accounts.. i'm not happy.. any other service shutting my down due to overload.. i'd tell them where to take their service

...whoops.. just crashed again

Again I can't login and it says on the grid status that logins are back so whats the deal?