|
|
|
[11:21] Show / Hide New RP Elements [script:tab_switch_buttons]: Script run-time error
[11:21] Show / Hide New RP Elements [script:tab_switch_buttons]: System.IO.FileNotFoundException: File or assembly name LSL_a7f8b646_c142_bbe9_dc3d_8822e639fbf5, Version=0.0.0.0, Culture=neutral, PublicKeyToken=7fdf2875deff985e, or one of its dependencies, was not found. File name: "LSL_a7f8b646_c142_bbe9_dc3d_8822e639fbf5, Version=0.0.0.0, Culture=neutral, PublicKeyToken=7fdf2875deff985e" at (wrapper managed-to-native) System.AppDomain:LoadAssembly (string,System.Security.Policy.Evidence,bool) at System.AppDomain.Load (System.String assemblyString) [0x00000] at (wrapper remoting-invoke-with-check) System.AppDomain:Load (string) at System.Reflection.Assembly.Load (System.String assemblyString) [0x00000] at System.Runtime.Serialization.Formatters.Binary.ObjectReader.GetDeserializationType (Int64 assemblyId, System.String className) [0x00000] at System.Runtime.Serialization.Formatters.Binary.ObjectReader.ReadTypeMetadata (System.IO.BinaryReader reader, Boolean isRuntimeObject, Boolean hasTypeInfo) [0x00000] at System.Runtime.Serialization.Formatters.Binary Hey, baron – I was unable to repro this. Hopefully vek will have better luck. Importing...
Tested in Second Life Server 1.24.2.95109 on beta (aditi) - still able to duplicate in Sandbox Cordova
(object names slightly sanitized) [15:46] HUD [script:rphud_load]: Script run-time error Along with seeing the same error conditions as before, we see 4 new error conditions in 1.24.3
Seeing several new errors on Second Life Beta Server 1.24.3.95195 on beta (aditi) [17:38] txtStatus [script:rphud_stat_generic]: System.TypeLoadException: Could not load type 'Could not load type 'ng.Messagin'. [17:38] Status2 [script:SayLocalPosAndScale]: System.TypeLoadException: Could not load type 'System.Runtime.Remoting.Messaging'. [17:38] F6-Run [script:tab_handler_macro_btns]: System.TypeLoadException: Could not load type ''. [17:38] RPHUD - METER [script:load]: System.TypeLoadException: Could not load type '00000000-0000-0000-0000-000000000000'. This issue may be becoming a meta issue.
So far I see 10 different failure modes that may or may not be connected: 1. System.Reflection.AmbiguousMatchException: Ambiguous matching in method 2. System.NullReferenceException: Object reference not set to an instance of an object 3. System.Reflection.TargetParameterCountException: Number of parameter does not match expected count. 4. System.Runtime.Serialization.SerializationException: serializationStream supports seeking, but its length is 0 5. System.IO.FileNotFoundException: File or assembly name LSL_a7f8b646_c142_bbe9_dc3d_8822e639fbf5, Version=0.0.0.0, Culture=neutral, PublicKeyToken=7fdf2875deff985e, or one of its dependencies, was not found. 6. System.TypeLoadException: Could not load type '00000000-0000-0000-0000-000000000000'. 7. System.TypeLoadException: Could not load type ''. 8. System.TypeLoadException: Could not load type 'System.Runtime.Remoting.Messaging'. 9. System.TypeLoadException: Could not load type 'Could not load type 'ng.Messagin'. 10. no message. It looks like this: Reopened internal issue. Downgrading to Major to match internal priority. Not a showstopper because it doesn't break existing content. It does prevent some content from converting to Mono, and so it will be among the first known issues for investigation.
I'm having similar problems. I'm getting the following error message:
[9:05] none [script:Piece Transformer Script]: Script run-time error [9:05] none [script:Piece Transformer Script]: System.Runtime.Serialization.SerializationException: serializationStream supports seeking, but its length is 0 at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.NoCheckDeserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler) [0x00000] at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream serializationStream) [0x00000] at LindenLab.SecondLife.Script.Deserialize (System.Byte[] object_data) [0x00000] at LindenLab.SecondLife.Script.Deserialize (System.Byte[] class_data, System.Byte[] object_data) [0x00000] However, this error started a few days after the script was compiled into mono... Currently, only one of fifty identical scripts is being effected by this error. I personally believe that this does break content, since it was working without giving errors on mono, until today. Cheshyr Ponchartrain released v3.0 of his emDash product yesterday...ran fine until I relogged after a crash this afternoon, when it started throwing:
[11:26] Status [script:emoter]: Script run-time error ...every time it is attached. I wonder at what point does a Mono script become "existing content"? I wonder if there have been anybody brave enough to compile and run serious scripts in Mono on the Main grid just yet. Anyway, I did it yesterday at Purgatorio, 'Kingdom of Sand'.
Since the upgrade of the server 1.24, we have had serious lag on the object-to-object communication on the LSL2VM (delay of 10 minutes instead of seconds). All the code was running fine before Friday, so it must be related to the upgrade. Because of the serious delay that made impossible to play in the SIM, yesterday I compiled our meter (capture/combat) and HUD to Mono (what did I have to lose anyway?). It is a pretty elaborated code, but it has been running fine before Friday. I tested it myself in Mono, and it seemed allright, so I released to the other players, and we got the SIM to crash and runtime errors such as: [19:41] Object [script:{KoZ} Child Location]: Script run-time error [19:41] Object [script:{KoZ} Child Location]: System.IO.FileNotFoundException: File or assembly name LSL_afdb909f_2f44_fae0_7ecb_adf981650567, Version=0.0.0.0, Culture=neutral, PublicKeyToken=7fdf2875deff985e, or one of its dependencies, was not found. File name: "LSL_afdb909f_2f44_fae0_7ecb_adf981650567, Version=0.0.0.0, Culture=neutral, PublicKeyToken=7fdf2875deff985e" at (wrapper managed-to-native) System.AppDomain:LoadAssembly (string,System.Security.Policy.Evidence,bool) at System.AppDomain.Load (System.String assemblyString) [0x00000] at (wrapper remoting-invoke-with-check) System.AppDomain:Load (string) at System.Reflection.Assembly.Load (System.String assemblyString) [0x00000] at System.Runtime.Serialization.Formatters.Binary.ObjectReade [script:~KoS~ OOC Chat 2008-08-31]: Script run-time error [19:42] [script:~KoS~ OOC Chat 2008-08-31]: System.Reflection.AmbiguousMatchException: Ambiguous matching in method resolution at System.Reflection.Binder+Default.GetBetterMethod (System.Reflection.MethodBase m1, System.Reflection.MethodBase m2, System.Type[] types) [0x00000] at System.Reflection.Binder+Default.SelectMethod (BindingFlags bindingAttr, System.Reflection.MethodBase[] match, System.Type[] types, System.Reflection.ParameterModifier[] modifiers) [0x00000] at System.MonoType.GetMethodImpl (System.String name, BindingFlags bindingAttr, System.Reflection.Binder binder, CallingConventions callConvention, System.Type[] types, System.Reflection.ParameterModifier[] modifiers) [0x00000] at System.Type.GetMethod (System.String name, BindingFlags bindingAttr, System.Reflection.Binder binder, CallingConventions callConvention, System.Type[] types, System.Reflection.ParameterModifier[] modifiers) [0x00000] at System.Type.GetMe I voted for this BUG, hoping that it will be fixed soon. In the meantime I am unable to continue further testing. I surely don't want the sim to crash again. Our SIM has an average of 40-60 players (busy) and about 2500 active players. Before Friday we were able to play with an acceptable lag, considered the traffic. Now it is just impossible. Thank you. I just had my whole Sim of Mono compiled items melt down. Everything in the vicinity of where I was standing crashed simultaneously, and maybe more outside my chat range. I have sent a sample item to Vektor as well.
[Please See Log file attached to this JIRA] In all cases the items were rendered inoperable and had to be recompiled. It was very odd they all occured at the exact same second. Some items were HUDS, some were in-world objects, items belonged to multiple people, some were self-created, some were bought from creators. The only common thread they all shared was being in that sim at that particular moment. Strangely enough, not all scripts in all items were affected. Perhaps only scripts performing an event at the time of the backend failure? I recompiled a combat meter as Mono yesterday. Since launch yesterday then we have had about 4800 active users using it in the past 24 hours, in those 24 hours there are 2 cases of exception number 4 above:
4. System.Runtime.Serialization.SerializationException: serializationStream supports seeking, but its length is 0 I would say given this that you need to have 4800 users running it and yet just get 2 cases then a lot of scripts probably could suffer from those issues without knowing it, making it perhaps more of a showstopper that it seems. I have personally seen the above failure 6 times in the last two days, so I think it's even more prevailent than one may think. And after having half the scripts in my sim crash, I have rolled back the release of my Mono compiled products. I can't risk foisting this issue onto my customers.
While I think a full sim worth of scripts crashing is a Showstopper, I'll let more learned eyes look over this and make that decision.
I'm tentatively linking this to VWR-575 (request to allow users to reset scripts in no-mod objects, although a similar argument could be made to recompilation).
It does sound from the descriptions that a runtime error condition in the mono script engine can render a script inoperable pending a recompilation. Moreover, Darien's experience suggests that some crashes of the mono script engine could render scripts across the sim to be inoperable until recompiled. Whilst prevention is better that cure, there will inevitably be bugs and crashes, and allowing the owners of objects some ability to recover when such things happen seems important. Please feel free to unlink, if I'm misinterpreting the problem being reported. I've bee able to duplicate these errors by rezzing an object containing scripts running through MONO about a dozen times. After the error occurs, sometimes the sim crashes and other times it doesn't. I have a feeling that these MONO bugs could be exploited and used to crash many regions... and the gray goo barrier would not be able to prevent this from happening.
Allowing (no mod) objects to be reset will not resolve this issue. Some scripts are not meant to be reset and if they were the content creator would have included a script that will reset all of the scripts in the same object. This may be a temporary solution to certain types of MONO problems but it would also cause problems for certain types of content. I wouldn't want to reset my in-game server which keeps track of a bunch of different things. As posted in issue
I would say this is not a matter of letting people reset/recompile etc. It is a matter of making sure script compiled under mono work the same as script compiled under LSL. If there are any differences then we need to have run time error messages that help track down the error in the script source. Darling I just did some initial testing on the beta grid against: Second Life Beta Server 1.24.4.95508 (Aditi)
I recompiled under the new server, and waiting 15 minutes after saving the objects back to my inventory. Upon the first detach, Issue 2 and 10 (Object reference not set to an instance of an object & Empty Error) both occurred. Once issue 10 is presented, I see it again on that object every time it is reattached until the scripts are reset. After resetting the scripts, the error reappeared within a few attempts. Update: After further testing, I've now seen each of the errors above in 1.24.4 except the TypeLoadException: Could not load type - this one was very rare for me, so if other users have scripts that more frequently obtain this condition, take a moment to go test in Aditi From QA, testing on 1.24.4:
"Tried to reproduce with the WARPS HUD to no avail, need a better repro!" Baron anything you can give Vek to help QA repro this will be appreciated. I'm running into the same / similar issue with the RPS HUD / Meter system. Here's what we've been able to find:
1--The failures seem to affect only scripts in which there is an actively running Loop or Timer. Out of 75 scripts in the RPS, only Looping/Timer scripts have been affected by this error. 2--The failures occur only when a region crashes while the player is wearing their HUD in it. Post crash, the error occurs with 100% certainty on login. 3--Picking up a new HUD-object solves the issue. I'm willing to help try to repro this error with and Linden who'd like to contact me. We can crash my island on purpose if you want Error Seen: [11:30] BNJ--RPS HUD,2.08.00 [script:TIMER_UPDATE]: Script run-time error Same issue here...
I concur with Kenn Nilsson comment above:- "1--The failures seem to affect only scripts in which there is an actively running Loop or Timer. Out of 75 scripts in the RPS, only Looping/Timer scripts have been affected by this error." I have a game inworld that calls various slave scripts (timer based) and it is these parts of the game that cause this exact problem. This i know because the parts in question are seperate to the main game itself and are rezzed on temp. (although i dont suspect the temp rez is responsable in any way) When game is started... all runs well for a while... then the sim begins to struggle and intermittent pauses become apparent. If play is continued this behavour becomes worse until sim crashes. This crash is 100% guaranteed with this game atm... happens every time. If demonstration necessary or needed then plz contact me mr/ms linden and i will be happy to oblige Adding one more comment...
Players have commented that on bad/failed/especially laggy sim-crossings (we operate several multi-region areas) the error also occurs. While I don't doubt Kenn's and louise's observations are true, It's not true in the cases I've seen. Many of the scripts which have crashed contained no timer or loop, they were in fact link message or listen based. However, they could still be active at the time of failure, due to receiving some stimulus to cause the respective event to run. In fact in one confirmed case, the script was nothing more than a state_entry() event with a single line to set llTargetOmega(). Nothing else. (see the log above, script "key spinner_1")
I wanted to add one possibly relevant detail about the Zebulon incident. Prior to the event, I had released my collar update which upgraded the collars I sell to Full Mono scripts. The updater changes out approximately 30 scripts per collar (i would have to go in world to get an exact script count). There were around 100 updates completed in the 12 hours leading up to the sim meltdown. So there were approximately 3000 llRemoteLoadScriptPin() iterations completed in the sim. I don't know if this has a bearing on the issue or not, but may provide a clue. ARGH !!!
I'm seeing this kind of errors in one of my products that I just converted to Mono yesterday... The product in question is a teleporter, and I got two copies of it that became unresponsive to the touch without any apparent valid reason: one came back to life after resetting the script, but the other was still unresponsive to the touch after a full reset, and taking a copy of it into my inventory, and re-rezzing that copy in world made it issue the following error message: Cool Teleporter v1.10 (blue) [script:Teleporter Access]: System.Runtime.Serialization.SerializationException: serializationStream supports seeking, but its length is 0 Only a full recompilation of the scripts could cure this problem. I still got the broken copy in my inventory, if a Linden wishes to have a look to it... The server is currently v1.24.4.95600, but the first problem was noticed when it was still 1.24.3.95195, Note that the sim where the teleporters were rezzed crashed at least 3 times since it was "upgraded" to v1.24.3, so perhaps the crashes broke the script, before the update to 1.24.4... This error is still present in server 1.24.4, including on newly compiled Mono scripts. This leads me to suspect that the compiler in the client is the culprit. I for one have been forced to use the beta server's client, redirected to Agni. The so-called RC0 is nowhere near a release candidate. It doesn't even function on the main grid. The moment I try to edit a script, it crashes.
The compiler for Mono is Server Side, so the client shouldn't play much of a role in this issue, if any. I don't think 1.24.4 was meant to address this issue, at least, it wasn't mentioned in the release notes. They have 1.24.5 slated on the calendar to start rolling out next week. Perhaps it has some bearing on this issue, but I don't know. I will certainly bring it up at Fridays Meeting with Periapse Linden.
 We've been given a number of objects which cause the "Serialization.SerializationException: serializationStream supports seeking, but its length is 0" error when rezzed, thanks.
This error is caused by the serialized form of the script being 0 length, so it can't be restored when rezzed and will remain broken until reset. I think it's a symptom of an earlier error, the System.Reflection.AmbiguousMatchException which is thrown during serialization, causing the serialization to fail and produce a 0 length vector which can then not be deserialized on rez. We haven't been able to repro the earlier error. If anyone could help us with that we would be very grateful. I'm not saying you're wrong, Darien, but if the compiler is server side, why does compiling say "downloading" first, and immediately crash the RC0 client 10 times out of 10?
Re 1.24.5, I hope it solves the other MONO problem. That of mono scripts being about 10x SLOWER than LSL versions. Simple scripts are taking 10 seconds or longer to run, where they took < 1 second on LSL. Thanks to louise rumpler we now have an object we can use to reproduce at least a subset of these problems and will look in to it further tomorrow.
@Babbage Linden
>We've been given a number of objects which cause the Resetting the crashed script does nothing at all for me: I must recompile the script to get the object to resume normal operations. > I think it's a symptom of an earlier error, the System.Reflection.AmbiguousMatchException By serialization, I assume you mean the storage of the script and its state in the DB ? For info, the two objects on which I saw this error occurring so far are copies of a same object which are permanently rezzed in the sim, with many other copies of the same object which are working just fine, meaning the serialization of the script was successful on rezzing and did not trigger an error in the other objects. I would be suspecting something going wrong when the sim crashes or on crash recovery: my home sim went kaboom no less than 6 times since the update to v1.24.3 (against 2 times in over a year or so before v1.24), among which two times today, under 1.24.4. > We haven't been able to repro the earlier error. If anyone could help us with that we For what it is worth, I sent you a copy of the crashed object. Cheshyr, I can't speak to the specifics of what the viewer does or doesn't do. I have been involved in the Mono project since it opened on the beta grid over 6 months ago, and I can assure you, the compiler is server side. I know the viewer acts as sort of conductor, directing the sim to scan the contents of each prim and find the scripts, and directs the sim to compile said scripts. However, the scripts are never sent to the viewer, to my knowledge. Perhaps the 'downloading' is vestige of the old method, which is still present, since LSL is still supported. In the case of LSL, the viewer does the compiling.
I have been using1.21 RC0 since it was released, and while I have crashed many,many, many times, i have yet to crash while compiling a script to Mono. You should probably open a seperate JIRA under VWR on that issue. Updating the issue to reflect the fact that this bug is still present in the current server version (1.24.4.95600): One of my attachments (worn as a HUD) gave me a deserialisation error on logging in:
Cool Sensor v1.30 [script:Sensor Probes]: Script run-time error After this error, the crashed script was impossible to restart with a reset: I had to recompile it. This is a really serious issue as commercial products got no-mod scripts and can't be recompiled by the end user, leading to irremediably broken item. Pretty please, fix it already ! Another reported incident this morning by PsychicMedium Meri Indigo.
[22:15] TARDIS Type 70 [script:Type 40 Controls]: Script run-time error [22:15] TARDIS Type 70 [script:Type 40 Controls]: System.Reflection.TargetParameterCountException: Number of parameter does not match expected count. at System.Reflection.Binder.ConvertArgs (System.Reflection.Binder binder, System.Object[] args, System.Reflection.ParameterInfo[] pinfo, System.Globalization.CultureInfo culture) [0x00000] at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] at LindenLab.SecondLife.LslUserScript.OnEvent (ScriptEvent evt) [0x00000] at LindenLab.SecondLife.Script.Run (ScriptEvent evt) [0x00000] Honestly, this error needs to be bumped to showstopper, as it is rendering the grid useless. Ive given DCS 2.40 to babbage which does it out of the box it was a fresh compile and sent.. Wear it it Reflection errors.
And yet another Mono-compiled script error on an attachment:
Cool Collar v2.80 [script:Collar Leasher]: Script run-time error Interestingly, the attachment was being worn for a while (so it was not a deserialization error this time) and shortly (30s or so) after this error spuriously popped up, the sim crashed (for what must be the sixth Interestingly as well, the attachment was fully functional after the sim restart (I guess the script state just did not have the time to make its way to the DB because of the crash, and the attachment was therefore deserialized from the state in which it was when it was last detached). Babbage,
If you've been able to track down the serialization error, does that mean we should be expecting a fix to that area of these errors soon? I've held off on transferring any of my other scripts to the Mono engine as a result and have quite a few players waiting eagerly for a time frame from Linden Labs... Today, in Ahndang, things have gotten to a point when it is impossible to use Mono scripted attachments... Each time you TP in or out of the sim, all your Mono scripted attachments break with (I don't have this problem when teleporting between other sims). I uploaded here an extract of a log file after a TP from Ahndang (see "Ahndang_TP.txt") as an example...
This is probably something that could be (at least partially) cured by a sim reboot, but I did not ask for one on purpose, so that if a Linden is curious enough and come see what happens, they may perhaps have a chance to figure out what's wrong. Interestingly, while the sim crashed over 6 times yesterday, it seems "stable" today... Perhaps the part of the server software which is responsible for Mono scripts serialization is what made it crash and what is not working at all today (thus not crashing the sim any more)... In any case, I spent the day reverting all my scripts and products to LSL2 (and sending the corresponding updates to all my customers) as in the current state, this bug is a show stopper as far as Mono is concerned. With the successful migration to Havok4, I was expecting things to go smoothly as well with Mono... I guess I have been way too optimistic At Friday's Mono meeting, Vektor Linden said the Rolling Restart for 1.24.5 scheduled for next week would have a partial fix for this issue, solving some of the types of failures. He also said Babbage is on the trail of the rest, so there is some progress being made.
Honestly, compared to Havok 4, this has been a good rollout. Havok 4 had the benefit of a long "Early Adopter" period (I was one of them), and even still had to have many revisions before it was considered 'stable'. But don't get me wrong, the H4 rollout set a new standard of professionalism which few have matched since. (waves to Sidewinder It's a real pity it was seen that an early adopter process was seen as not necessary, many of these problems could have been trapped early rather than releasing the new server grid wide knowing there will be people who had "drunk the kool aid" and would convert anything and everything and send it out to their customers.
Even without the benefit of all regions being Mono active thus not being able to fully test things like TP's there was huge scope to trap some of these problems we are seeing now. Havok4 was done right, Mono... not really. It is difficult to see how an early adopter roll out would have worked.
With the Havok4 rollout - a vehicle designed for Havok4 should work on a Havok1 region (and vice versa). Exceptions being either bugs or edge cases. With mono, if LL did a partial rollout, then a mono-compiled script if introduced onto a region not running the mono-VM would either fail to work or crash things horribly - most likely the latter but even if the former, it would probably not result it much wider testing than on the beta grid as content creators would be unlikely to to release a product which only worked on certain sims (and deal with the support issues). Why is it difficult? Programmers are more intelligent than normal people, not less. Anyone with an interest and need in the early adopter program would have the brains not to distribute MONO-compiled products until the server-wide roll-out.
Every one of the problems in the MONO release were due to the lack of an early-adopter program. E-mail failed because the beta grid disables e-mail, preventing it from being tested. Estate tools are broken on the main grid now, because they're disabled on the beta grid, and thus weren't tested. Repeat for all other MONO problems.. This issue has affected my product (KKF ScanHud).
It seems to be directly related to the functions which manipulate the position or rotation of prims. If my spidey senses are working, it seems that on laggy sims, mono get confused about the state of prims somehow... I've downgraded part of my product back to LSL2.. it was causing sim crashes!! = Cheshyr,
You answered your own question - "Anyone with an interest and need in the early adopter program would have the brains not to distribute MONO-compiled products until the server-wide roll-out."! Precisely because content creators would not distribute mono-compiled products until a full-wide roll-out (i.e. after any early adopter roll out) would mean that the level of testing on the main grid during any early adopter rollout would not be significantly larger than the level of testing on the beta grid. The severity and frequency of this particular issue only came to light when content creators began grid-wide roll outs of mono-compiled products. Whilst it may have been caught during an early adopter phase the probability of that is not much higher than it doing so during the beta grid phase. The same applies to many of the other MONO issues - they only come to light when there is a critical mass of MONO-compiled objects, a critical mass which would not emerge until after a large number of content creators tries distributing MONO-compiled products rather than a small number trying out limited rollouts of them. The e-mail problem might have been caught - but don't forget that LL have 1.24 installed on a small number of regions for a few days before rolling out to the rest of the grid in order to pick up precisely those sorts of issues, and that issue wasn't picked up during that (albeit short) early roll out. I'm not sure what the estates tools problems you refer to are - the only ones I've seen to date relate to the 1.21 RC viewer and aren't present in the normal 1.20 viewer. Actually we did test Email on the Beta Grid, I know I ran some tests, as did a few other beta testers. However, I have to confess I've never used the filter option for anything, ever, and didn't try it then. It could also have been a case where it was working at the time we tried it, and broke later after we had moved on to other things. There were a lot of things to cover and a lot of interim versions of the server code. I know I have learned something from that, and I'm positive LL has too.
I don't know of any Estate tool issues directly related to Mono either, However nearly all of the testing was concentrated on Mono, not on other server functions unrelated to Mono itself. So blaming any issue in estate tools on the Mono team is quite a stretch. I and many others tried to test llEmail on the beta grid as well. It always failed, 100% of the time, and no filtering was involved. When I asked why it wasn't working, I was told that Linden Lab had disabled llEmail() on the beta grid to avoid "contamination of the main grid."
As for estate tools, They don't work at all in the 1.21 clients. You get garbled results, a name field that's too small to read, and no ability to sort or even change the field width. While 1.21 isn't only for Mono, it is directly related. And more to the point ,the new fantasy "mono time" field shown on estate tools always reads 0.0. For every script in every sim, whether compiled to MONO or not. Clearly broken. Babbage and Scouse have checked in a fix.
The fix has been deployed to aditi for testing in beta server 1.24.5.96115 Sadly, server 1.24.5.96115 doesn't fix all the C# errors. And this is pretty much a show-stopper.
This pretty much happens all the time with my HUD, whether 1.24.4 or 1.24.5.96115: [0:46] LULU Signature Command HUD [4.98.02] test [script:_LULU.sR.lsl]: Script run-time error Lulu, did you recompile the object in question in a 1.24.5.96115 region? Do we know if that even matters?
LL has added more fixes for this issue to 1.24.5.96378, it's being re-rolled as I type. Maybe check your item against this newest version?
1.24.5.96378 seems to be working fine so far. Let's keep our fingers crossed.
Second Life Beta Server 1.24.5.96378
I got this error after removing my hud and putting it on a second time. The frequency of this error seems MUCH higher than 1.24.4 (but could be because other failure modes are being removed): [16:41] HUD [script:rphud_stats]: Script run-time error Once the error occurs, it repeats every rez, every teleport, every sim crossing unless the scripts are all reset. I was also still getting the serialization errors in 1.24.5.96115, but still testing for that now. It seems much less frequent. Second Life Beta Server 1.24.5.96378
I also noticed a very high risk (showstoper) sim crash with 1.24.5 related to this, described steps to reproduce to Vektor Linden in detail and demonstrated. Looks like I spoke too soon. Looks like things are more stable, but the problems aren't all gone yet.
[17:45] LULU Signature Command HUD [4.98.10] [script:LULU.oM.lsl]: Script run-time error Second Life Server 1.24.5.96378 Received this mono error in Second Life Server 1.24.5.96115 whilst TP'ing into a region with my KKF Scanhud which I have provided to vektor and babbage.
[0:55] KKF ScanHUD MONO v1.7 [script:closerangeradar]: Script run-time error Now I get tons of this:
[21:51] Hinge2 [script:LULU.sc.lsl]: Script run-time error Second Life Server 1.24.5.96378 In testing on the new version on Aditi - Second Life Beta Server 1.24.5.96547
I'm still frequently able to produce this error: [9:50] HUD [script:rphud_stats]: Script run-time error The crash issue for 1.24.5.96378 is resolved. I got error message when using llBase64ToString with specified data.
Error message: Script: Server version (both): Fake, I can consistenly reproduce that bug as well. However I suspect it may be seperate from this issue. This JIRA is about scripts crashing that were working normally for some time. Your bug seems to be a real bug in the llBase64ToString() function, as it never works.
I would strongly suggest opening a seperate JIRA on this, Filed under SVC, Server 1.24, component Scripts. And be sure to include Mono in the title. Fake, Darien, I agree that this is a separate issue. I have opened a JIRA issue here:
Many thanks for the information, we will take a look into what is going on. All progress will be reported in 1.24.6.96673 has been deployed to the "Second Life Beta Server" regions on the preview grid and includes a number of fixes for these issues.
Please test any objects that were causing problems on those regions before Wednesday. Objects that were previously broken may still report errors on rez, but should work normally after reset. Objects that previously caused crashes should no longer do so. @Babbage Linden
If you want true beta-testing, then you need to deploy the beta version on the production grid (could do it in some Linden-ran sand boxes): on the beta grid, my inventory is months behind and I cannot afford spending enough time on the beta grid, hoping that the bugs will happen (most of them being perfectly random and needing hours to appear). The success of Havok4 deployment was largely the result of the tests done on the main grid... Mono should follow the same route if you want to make it usable after a reasonably short period of testing @ Babbage:
can you sync inventory with agni? A lot of big script I use on the grid isn't avaiable in my inventory on beta..... Babbage – I spoke with Tayra and refreshed her inventory on aditi.
Second Life Beta Server 1.24.6.96673 - on Aditi
Vektor and I were both able to reproduce the Object Reference error. And the objects do not fix after this error on re-rez. Have to manually reset. It's only about 2-5% of the time, and we both saw it following a message that we had attachments pending. [16:35] Cannot complete attachment. An attachment is pending for that spot. Regarding Babbage's comment about old errors clearing up - I rezzed many of my broken objects with the serialization error and the error is presented on the first rez, and the object works normally on the 2nd rez/attach. (Lots of good progress, everyone - I'm not seeing nearly the issues I was 2 weeks ago, thanks for following this issue and helping us get it closer to resolution!) Here is an exception reported that isn't mentioned above (as listed in
[12:32] Vendor [script:.CheckData 2.3]: Script run-time error Looks a bit like the GetNextQueuedEvent tried to index into the event queue incorrectly (wild guess). One more for the collection:
Second Life 1.21.0 (94415) Aug 14 2008 15:18:57 (Second Life Beta) regular (production) grid on the beta client [sorry for the repeat edit spam] //---------------------------------- [9:14] 3 [script:Avadar HUD-Display]: Script run-time error [9:14] 3 [script:Avadar HUD-Display]: System.Reflection.TargetParameterCountException: Number of parameter does not match expected count. at System.Reflection.Binder.ConvertArgs (System.Reflection.Binder binder, System.Object[] args, System.Reflection.ParameterInfo[] pinfo, System.Globalization.CultureInfo culture) [0x00000] at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] at LindenLab.SecondLife.LslUserScript.OnEvent (ScriptEvent evt) [0x00000] at LindenLab.SecondLife.Script.Run (ScriptEvent evt) [0x00000] To get a very repeatable means of causing this error/spam.
Let this run till it stack heaps, take to inv, re-rez... spam default Posted a repro for the 'System.Reflection.TargetParameterCountException' error here: http://jira.secondlife.com/browse/SVC-2975
Repros on both agni and aditi. Second Life Server 1.24.7.97922
Second Life Server 1.24.7.98039 [15:17] HUD [script:rphud_load_stats]: Script run-time error I am still seeing this error pretty frequently reproduced again today on agni and aditi. Once this error occurs, the script stops functioning until it is manually reset. And another after today's server patch (Second Life Server 1.24.8.98496)
[19:37] TARDIS Type 70 [script:Crypt Controls]: Script run-time error And again, twice
[19:42] TARDIS Type 70 [script:Type 40 Controls]: Script run-time error [19:42] TARDIS Type 70 [script:Type 40 Controls]: System.Reflection.TargetParameterCountException: Number of parameter does not match expected count. at System.Reflection.Binder.ConvertArgs (System.Reflection.Binder binder, System.Object[] args, System.Reflection.ParameterInfo[] pinfo, System.Globalization.CultureInfo culture) [0x00000] at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] at LindenLab.SecondLife.LslUserScript.OnEvent (ScriptEvent evt) [0x00000] at LindenLab.SecondLife.Script.Run (ScriptEvent evt) [0x00000] [19:43] TARDIS Type 70 [script:Type 40 Controls]: Script run-time error [19:43] TARDIS Type 70 [script:Type 40 Controls]: System.Reflection.TargetParameterCountException: Number of parameter does not match expected count. at System.Reflection.Binder.ConvertArgs (System.Reflection.Binder binder, System.Object[] args, System.Reflection.ParameterInfo[] pinfo, System.Globalization.CultureInfo culture) [0x00000] at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] at LindenLab.SecondLife.LslUserScript.OnEvent (ScriptEvent evt) [0x00000] at LindenLab.SecondLife.Script.Run (ScriptEvent evt) [0x00000] Since 1.21 has been pushed out of the door prematurely, i'm raising the priority of this report.
you can roll out any fixes you like to the region "QUANTUM". My entire product line is always in-world in this region and I will quickly detect any issues. Going to the beta grid for 4-8 hours at a time waiting for a random error is not a practicle way to track a crash in commercial products. However i'm happy for my private region (which is open to the public) to be loaded with the latest beta versions for testing.
Darling Brody. Still happening, got this yesterday and I'm getting from purchased products that use Mono not just my own stuff
script:LOClient UuidCache]: Script run-time error Issue still present in 1.24.9.98659
[21:50] KKFErrorReport: ERROR REPORT - USR: Ficky Fride VRS: 1.680000 MSG: KKF ScanHUD MONO v1.68&9539466 [script:ops]: Script run-time errorr Honestly, mono should have gone through the same volintary rollout as havok4. Those of us who script for a living would have converted one of our regions and these problems would have been fixed before they hit the main grid.
If I ever catch the person who decided to roll it out this early standing in a havok1 sim they are going to get orbited! Darling Brody. I've just tried to run a command on a Texture Organiser that runs fairly well under lsl and got several versions of:
Cat30 [script:Category control]: Script run-time error (only with different Cat numbers). Not sure if it will help with the bug hunting, but I have 49 "Cat" buttons with identical scripts. 8 of them threw this error, the other 41 were fine. There are actually 78 scripts in total, the other 70 were all fine. Hi Eloise,
There are numerous JIRAs for this type of issue, as you can see linked above. I know a few of them have been resolved with the 1.25 server version which is currently baking on the Preview Grid. You may want to try your application there, to see if it resolves the issue. The sim I used which is running 1.25 is here: You can find information for connecting to the preview grid here: This passed QA with last version of 1.24 server.
Err... which "last version of v1.24" ?...
AFAIK, the next version will be v1.25... If you mean the v1.24 currently in use (1.24.9.98659), then I must point out that more bugs where reported here after this version was rolled out on the grid: the last successful grid-wide rolling restart announced by LL was on October the 5th (http://status.secondlifegrid.net/2008/10/05/post273/ The fact that your QA team could not reproduce the bug does not mean it does not exist any more, as prove the 3 reports above that all occured after v1.24.9.98659 was rolled out. I'm reopening this issue, as it is obvioulsy still not fixed in v1.24. Henri: not to try to undermine what you said, but just for the record I'm seeing this as fixed in both my "loop til it dies" example above (very reproducible...albeit an intentional production of an error state) and the HUD that would occasionally spam these errors.
Second Life 1.22.0 (103519) Nov 20 2008 15:37:22 (Second Life Release Candidate) You are at 251776.0, 231808.0, 4001.4 in U Delaware II located at sim3714.agni.lindenlab.com (216.82.22.195:12035) Second Life Server 1.24.9.98659 @Betlog
I do not deny the fact that things got better and that the bug is triggered much less frequently. But the fact that three different residents encountered this bug after the v1.24.9.98659 server version was rolled out is a proof that this bug still exists. It may get tirggered only once in a million, but it is still there. This issue shall therefore remain open. It is not fixed. It is happening a lot less often, but it is still happening. Especialy in HUD objects with lots of link messages wizzing around all the buttons.
1.25.x is meant to contain more fixes. so lets leave it open until that hits the main grid for a while. Darling Brody Yup. I do not disagree. I'll certainly notice it if it happens to my HUD again. (24x spam...same situation as darling mentioned).
Relax Henri :] This is still an issue for me too.. The frequency has been reduced, but I'm still having 5 users or so a week report it breaking.
It's frustrating to me when the IMs come in bashing the item or design or me personally, but it only takes a moment to explain that it's a LL issue and they're aware of it and working on it. (I just wanted to point out the observation that there's a cost to our reputation for this issue too) baron, your are right. It makes all the hard work we put into quality control pointless when our products are spewing errors and our customers are talking about how bad our scripts are. And it is something that is going on all the time, 90% of which we never see or have a chance to explain.
hay LINDEN LABS, How about announcing on the main blog that the error is fixed. (when it is fixed) Darling Brody Second Life Server 1.24.9.98659
[21:07] KKFRadar [script:PrimaryRadar]: Script run-time error Yep, I also have to confirm the above stated. The frequency has become less, but it still occurs with server 1.24.9.98659
It seems to happen especially with scripts which receive a mixture of many linked messages and sending IMs which work in a laggy environment (many avatars present). Possibly an overflow in an event queue? Same here:
Second Life Server 1.24.9.98659 System.Reflection.TargetParameterCountException: Number of parameter does not match expected count. The fix might not be deployed yet. For the System.Reflection.TargetParameterCountException issue as seen in
Issue still present in Second Life Server 1.24.10.106829
Thanks to my automatic error reporting in my products, I can see whan any of them crashes out. ERROR REPORT - USR: <removed> VRS: 1.680000 PRODUCT: KKF ScanHUD MONO v1.68 [script:ops]: Script run-time errorr Actually very annoying because 1.25 (fix pending) was said to be deployed beginning of November and it had been postponed several times and I am not sure if the deploy mid/end of january will succeed.
We really need a fix in 1.24.x if the next re-roll of 1.25 fails aswell (which no one hopes). The reputation of many scripters and their products is suffering from that and customers are loosing patience when we tell them to wait for 1.25 over and over for the past 2 month. An serious error like this in a core component like the scripting engine can't stay unfixed for 2 1/2 month Second Life Server 1.24.10.106829 [script:whatever]: System.Reflection.TargetParameterCountException: Number of parameter does not match expected count. at System.Reflection.Binder.ConvertArgs (System.Reflection.Binder binder, System.Object[] args, System.Reflection.ParameterInfo[] pinfo, System.Globalization.CultureInfo culture) [0x00000] I'm getting the TargetParameterCountException thrown, usually immediately after TP or LOGIN.
My problem might not be Mono-specific, as the same script produces a cryptic "Index Error" if not compiled with Mono, under similar conditions. One odd thing: The probability of the error occurring seems linked to the speed of the user's connection. It happens repeatedly (but not repeatably) on my fast connection; I have never yet managed to reproduce it on my slow connection. Upon rezzing a hippoSECURE unit, v1.5 (mono), i receive this error:
[20:11] hippoSECURE v1.5 [script:networkManager]: Script run-time error The unit froze, needing a used "reset scripts in selection", worked ok, rezzed another, 15 minutes later: [20:26] hippoSECURE v1.5 [script:networkManager]: Script run-time error SIM was Calas Galadhon i am still seeing this on a sim that is running 1.25.3.107941, so it apparently not fixed in the latest roll out. -
: Script run-time error System.NullReferenceException: Object reference not set to an instance of an object at LindenLab.SecondLife.LslUserScript.OnEvent (ScriptEvent evt) [0x00000] at LindenLab.SecondLife.Script.Run (ScriptEvent evt) [0x00000] I am not sure what is really happening as it is intermittent. Yes Tomm, it is on the new rollout, i am an early adopter. Spritely, please paste the error you received. Also, make sure that the sim really is running that version; many haven't yet been upgraded.
At Periapse Linden's office hours Friday (01/16/08) He revealed that 1.25.3 actually reverted many mono fixes, there was a version control error.
So it's not surprising that you are seeing mono errors. It will be likely that old problems will resurface under 1.25.3. As to what LL's plans are, to rectify this, it is my understanding this will be decided once they gague the scope of the issue. Darien.. I honestly can't believe what you're saying, though it is obviously accurate. Mono was finally rolled out on the 29th of August, 2008, several months after it was originally planned for release.
[2008/05/08 14:48] Periapse Linden: we believe Mono is stable enough for the main grid now. Our hope is to get it into the pipeline for server deploy by the end of the month, and have it gridwide in early June We now have a situation where a core service, which has been out of beta and in gridwide release for nearly half a year, is still broken. Not only is it broken, but it's also causing supported content to break and fail. I am employed by a company who have sought to invest into Second Life and the technology, and are building a project which depends on mono technology as promised to us a year ago. Linden Lab have repeatedly failed to deliver, as they failed to deliver Windlight as promised ( VWR-7677 ). I should also note that there was a successful gridwide service rollout, namely Havok 4. Unfortunately, it appears that the person who orchestrated this deployment is no longer working for the company (Sidewinder Linden). As a business, Linden Lab are simply proving impossible to depend on. Well, all I know is what Periapse said Friday. He was clearly upset by what transpired, I don't think anyone wants these kinds of issues. He stated Scouse Linden was going to be going through the list of previous changes and seeing what was reverted, and what was not. I don't envy anyone having to do that, I've been there and it is not a fun task by any stretch.
Unfortunately in the real world, revision control can fail and it's something every company has to deal with. I don't feel this makes Linden Lab any worse or any better than any other company. This "TargetParameterCountException" and related are giving a lot of people a very hard time. And it's often impossible to explain this to angry customers why a product stops working under certain conditions. We all are dealing with this problems since september and the only thing we can tell people is: "The next rollout will fix it ... please, be patient and stop beating me up ..."
Fortunately many are very understanding and patient ... but if I tell them: "LL lost the fixes in version control and you will have to wait until the next fix ... probably in a few weeks ...", they will be even more frustrated than they already are. Darien: As a tech person I understand that things don't always go the straight way and that sh*t happens ... but we're waiting since september for a solution and each month we get another promise: "It will be fixed soon". And yes, we tested a lot in the beta grid with mono. But things in beta are different: you never experience lag like in a very crowded place, you hardly find 40 or more people who are willing to help you do stress tests etc etc. Sorry for the personal commenting on this, but I am tired of being the sand sack and there needs to be done something about these serious mono errors. Scouse did in fact go through the file that had the version control problem, and there was only one reversion – double touch events.
1.25.4 is looking good for a rollout right now. More information coming in a status blog post later tonight. It's good to hear the scope of the version control issue was limited. But that then makes these reports of further issues in 1.25.3 worrisome. I hope they are flukes caused by the general grid instability of the last few days.
Forgive me if i'm wrong, but it doesn't seem like "double touch events" in any way describes the "System.NullReferenceException" raised above in 1.25.3.
Does this mean that we are in an even worse situation now, where a fix isn't even in the pipeline? It is definantly more than just a double touch. I see this most often in attachments when i cross region orders, or when i turn on scripts in estate tools after they have been off.
It can also happen when just standing there AFK in a busy region. Did you get the object i sent you? i didnt get a reply to my IM's the other day. I stayed up all night waiting too.... Darling Brody. Inadvertently divided by zero.. but none-the-less it shouldn't do this still.
[23:31] AutoHUD [script:AutoHUD]: Script run-time error We're still "bricking" mono products and replacing them at the same or worse rate from 1.24. It "feels" worse in 1.25 but I haven't gathered hard numbers that validate it.
When I saw the error in testing, it was from detach/reattach... but most of the errors out in the wild people are reporting on sim crossings and TPs to new sims --------------------------- --------------------------- BETLOG or baron – can you please send me the asset ID of something that reproduces this error?
I found a certain repro for one error.
reproducible script default
{
state_entry()
{
state dummy;
}
state_exit()
{
llResetScript();
}
}
state dummy
{
state_entry()
{
}
}
Steps to reproduce.
Observed:
I checked in 1.25.4.108489 on agni and 1.25.5.109327 on aditi. Confirmed ... definately a stable repro ... usually on first or lastest second attempt.
Great work, Fake And the above repro (although giving different errors than the rest of the reports here, which relate to System.Reflection errors), still gives the same result with 1.25.5.109327 servers.
Anyone still seeing the System.Reflection errors in 1.25.5.109327 ? Still present in server 1.25.109327, as evidenced by this message:
[11:02] BREACH MP7 L 1.1 [script:MP7.Anims]: Script run-time error I have a new one for you. One of my clients reported this error when a simple mono script started. It crashed the sim too. If I understand the message correctly, the region is corrupted.
[4:20] Persepone Voss: Hi, I have not had a problem in a sim I've been working in, but in my home sim using HORIZONS v3.0 updated unit and content updated into a v3.0 crate (region running on server 1.25 for ref) ... I get this green spam upon rezz and then the sim crashes ...as follows [4:16] fuego5 [script:Gas Flamme]: Script run-time error [4:16] fuego5 [script:Gas Flamme]: System.IO.FileNotFoundException: File or assembly name LSL_790640d0_08a5_581b_cab9_7b8cbe8c79bc, Version=0.0.0.0, Culture=neutral, PublicKeyToken=7fdf2875deff985e, or one of its dependencies, was not found. I have also had issues with mono scripted teleporters ceasing to function (but hadn't known why until I read this page ). Today I had the nightmare as contained in the the above post by Cheshyr Pontchartrain that was continually crashing sims ,not just my home sim of Frolic , but Skidz Isle sandpit also . Linked a new issue reported by Argo Nurmi. http://jira.secondlife.com/browse/SVC-3915
One of my products ( a sculpty shoe) just output this error for a customer:
Shoes by Simone! - Boudoir Heels - R [script:SculptyFootColorChangerFootScript.lsl]: Script run-time error Unfortunately I cannot get you the item itself because it is no transfer. I'd be happy to hand a fresh copy, but this is the first time I have seen this error, so I can't guarantee you can reproduce it. The customer cant' remember what she did before it happened. If it helps, mostly likely what triggered this is another object trying to communicate with the shoe via a negative chat channel. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Reopened
Showstopper
C# error messages with Mono Compiled scripts
time today...).
) Mono didn't have this period on the main grid, so I'm not too surprised things cropped up once it was deployed grid-wide. Given rapid response to issues, I have good vibes that Mono will be 'stable' in short order.
"Serialization.SerializationException: serializationStream supports seeking, but its length is 0"
occurs, it repeats on rez & sim crossing, even after transferred to another user.