I finally got around to checking the backup of Akismet-flagged comments to my blog today, and found a very curious one from Darien Caldwell, who is also a (rather more well-known than I am) Second Life® scripter and content creator. This may provide a bit of a clue to the problem I posted about before :
I know I have seen some very stable scripted items start having troubles timed the day LL rolled out the latest server version with some unspecified changes to string operations. Since then, I have been having sporadic script crashes on items that never had issues before. Change to string operations referenced here:
Rolling Restart - Thursday March 6th, 5pm-10pm PST
“We’ve investigated the issue and have identified the cause. In the 1.19.1 server code we tightened up some bounds checking for string copies within the LSL string operations. After identifying this as the source of the performance degradation, we identified a fix - which maintains the bounds checking, but also surpasses the performance of 1.19.0 by approximately 10%.”
This somehow created a script crashing issue. But as the details of what changed were not made public, it’s impossible to to find the cause, especially when you don’t have access to the source code of the scripted item in question. But perhaps this will put someone on the right track.
I’m not exactly sure how the issue encountered by Darien could be related to the issues we have been seeing (we do many string operations, but are experiencing Math Errors), but it certainly does indicate that Linden Lab® has been mucking about with at least some of the core server-side code, with the unfortunate result that problems are cropping up in-world that never presented before.
Another comment I missed because of Akismet incorrectly flagging it as spam came from Aimee Congrejo, who not only provided a chat log with the actual times and location of the errors, but also indicated that it is not only happening on Havok™ 4 sims :
The first I saw this happen was *months* ago in Meiji and Tokugawa with an Ashes Cursed Spirit. I told the owner (freebsdd Allen) to IM Esprite but it looks like he never did cuz you guys haven’t heard of this before. ^_^ So it’s not new…but it’s pretty rare.
I’ve also seen a few blade breaks with the same error in Samurai Edo and Cold Steel.
Here are the times and logs from the TFS tourney (Samurai Edo):
[2008/03/08 15:07] Charly Moo: Script run-time error [2008/03/08 15:07] Charly Moo: Math Error [2008/03/15 15:14] Lumiere Zenovka: Script run-time error [2008/03/15 15:14] Lumiere Zenovka: Math Error [2008/03/15 15:39] Djinn Holiday: Script run-time error [2008/03/15 15:39] Djinn Holiday: Math Error [2008/03/15 15:43] Djinn Holiday: Script run-time error [2008/03/15 15:43] Djinn Holiday: Math Error [2008/03/15 15:47] Lumiere Zenovka: Script run-time error [2008/03/15 15:47] Lumiere Zenovka: Math Error [2008/03/15 16:23] Lumiere Zenovka: Script run-time error [2008/03/15 16:23] Lumiere Zenovka: Math ErrorErrors in a non-Havok™ 4 sim this afternoon when Djinn pulled his blade:
[2008/03/16 13:29] Djinn Holiday: Script run-time error [2008/03/16 13:29] Djinn Holiday: Math Error [2008/03/16 13:32] Djinn Holiday: Script run-time error [2008/03/16 13:32] Djinn Holiday: Math ErrorAnd blade random errors I have chatlogs for (no idea what sim but definitely pre-Havok™ 4):
[2007/09/20 21:31] freebsdd Allen: Script run-time error [2007/09/20 21:31] freebsdd Allen: Math Error [2007/09/20 21:31] freebsdd Allen: Script run-time error [2007/09/20 21:31] freebsdd Allen: Math Error [2007/09/20 21:31] freebsdd Allen: Script run-time error [2007/09/20 21:31] freebsdd Allen: Math Error [2007/09/20 21:31] freebsdd Allen: Script run-time error [2007/09/20 21:31] freebsdd Allen: Math Error [2007/11/27 21:17] freebsdd Allen: Script run-time error [2007/11/27 21:17] freebsdd Allen: Math Error [2007/11/27 21:17] freebsdd Allen: Script run-time error [2007/11/27 21:17] freebsdd Allen: Math Error [2007/12/09 12:14] freebsdd Allen: Script run-time error [2007/12/09 12:14] freebsdd Allen: Math Error [2007/12/09 12:14] freebsdd Allen: Script run-time error [2007/12/09 12:14] freebsdd Allen: Math Error [2008/02/16 16:43] Miss Siemens: Script run-time error [2008/02/16 16:43] Miss Siemens: Math Error [2008/02/16 16:44] Miss Siemens: Script run-time error [2008/02/16 16:44] Miss Siemens: Math Error [2008/02/16 16:59] Miss Siemens: Script run-time error [2008/02/16 16:59] Miss Siemens: Math Error [2008/02/16 17:05] Miss Siemens: Script run-time error [2008/02/16 17:05] Miss Siemens: Math Error [2008/02/16 17:10] Miss Siemens: Script run-time error [2008/02/16 17:10] Miss Siemens: Math Error [2008/02/16 17:11] Miss Siemens: Script run-time error [2008/02/16 17:11] Miss Siemens: Math Error [2008/02/16 17:14] Miss Siemens: Script run-time error [2008/02/16 17:14] Miss Siemens: Math Error [2008/02/16 17:15] Miss Siemens: Script run-time error [2008/02/16 17:15] Miss Siemens: Math Error [2008/02/16 17:19] Miss Siemens: Script run-time error [2008/02/16 17:19] Miss Siemens: Math Error [2008/02/19 21:19] Brenna Beck: Script run-time error [2008/02/19 21:19] Brenna Beck: Math Error
I’m not sure how this information will help, and I’ve not seen any reports of the issue since the 16th, but I’m still hoping that we can gather enough data to point out the problem to Linden Lab® and enlist their help in resolving the problems.
Popularity: 60% [?]
This has to be one of the worst (in terms of a developer trying to fix) bugs I have ever seen. I hate error messages that don’t really tell you anything other than “ZOMG I IZ BROKED!”, and it occurs so infrequently that without a way to reproduce it, knowing if a fix worked would take months.
Let’s start listing every possible way to cause a math error:
Division by zero
Um….. Let me see…..
Integer overflow?
There really aren’t that many possible math errors that I can think of, and none that would be a problem after months or years of operating correctly.
Archanox pointed out a possibility where some core function like llGetMass() is returning 0, thereby causing a previously-unencountered “division by zero” error.
Another one (yes, I’m grasping at straws) is vector normalization without checking for zero vector length first; we do a lot of math in the C:SI scripts, and much of that involves vectors, mass, and velocity, so it seems as likely as anything else I can think of.
It seems nearly crippling that there can be absolutely no error logging, no line numbers reported, no way *AT ALL* to determine the cause of the error.
It is a huge testament to the dedication and passion of Second Life scripters and content creators that they’ve done as well as they have with the rickety system they have to work with.
Note that when I mention vector normalization in the previous comment, I am referring to llVecNorm(), llVecDist(), and relatives, rather than our own hand-coded routines.
And now it occurred to me that some of these problems are reported as occurring simply by drawing the sword. Um, I cannot find any instance of performing any math at all during sheathing/unsheathing the sword
Something just occurred to me, I have seen a Math Error like this before, when attempting to use llSetColor on a face that didn’t exist. Why this causes a Math Error, I don’t know.
If the issue is occurring when drawing the weapon, perhaps it has to do with the call to llSetAlpha and the face parameter? Or trying to set alpha on a linked prim that doesn’t exist? Some wild guesses.
Oh, now that’s an interesting speculation!!!
We do in fact set alpha on a number of prims while performing the sheathing and unsheathing of a sword, and in order to reduce script counts we are doing that using llSetLinkAlpha() and relatives.
I can’t for the life of me imagine why there would *ever* be a case where we are trying to set color or alpha on a linked prim that doesn’t exist, since we never add or remove prims via script and the object’s prims are “set” once they are put up for sale, but perhaps related to lag or some other bizarre server-side behavior where the sim is not (yet?) aware of the prim whose alpha is being set? Okay, that’s probably the worst sort of voodoo speculation, but I am not sure where else to go at this point, haha.
Thanks for the comment Darien!!! It may prove to be an important clue.
Wow… It did just occur to me that most of the C:SI weapons use a notecard to define the links whose alpha is to be changed, and as I (and others) have recently discovered, it is not unusual for notecards to have suddenly become missing or corrupted.
I would ask Aimee and anyone else who notices these errors to please take note of which swords have the problem. Specifically, I’m wondering if the Wave Katana also experiences this issue, because the Wave does not use notecards (it has hard-coded link numbers).
If it can’t find the notecard, though, would it even get to the dataserver event to call llSetLinkAlpha? I suppose if it was corrupted instead of lost, it would go ahead and read bad link numbers.
That sounds like a possible scenario. I have products which also read notecards, and it’s not unusual for them to sometimes read bad data. I hope this leads to a solution. Have loved C:SI weapons since I was a wee newb.
Well Darien, I surely appreciate your input on this. When I finish the sword I’m working on, I’ll be sure to send you one! (of course, I seem to be taking forever to finish it, but I’m pretty sure it’ll be this month, haha)