Réunion du 28-06-2022
Source : http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2022-06-28
Introduction
- Traduction de la bande dessinée proposée par Kayaker :
2004 : Notre équipe reste en contact par IRC. 2010 : Notre équipe utilise principalement Skype, mais certains d'entre nous préfèrent rester sur IRC. 2017 : Nous avons presque tout le monde sur Slack, mais trois personnes refusent de quitter IRC et de se connecter via la passerelle. 2051 : toutes les consciences ont fusionné avec la singularité galactique, à l'exception d'un gars qui refuse de se connecter via son client IRC. Je l'ai juste configuré comme je le veux, ok !
[11:01] Andrew Hellershanks : Bonjour, tout le monde.
[11:01] Motoko.Karu @login.digiworldz.com:8002 : hihi
[11:02] Ubit Umarov : ohh ce sont des cochons dans les cheveux d'Andrew ?
[11:02] Ubit Umarov: :)
[11:02] Ubit Umarov: ( blague privée liée à irc )
[11:02] Vincent.Sylvester @hg.zetaworlds.com:8002 : hehe
[11:03] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il ne s'est pas passé grand chose cette semaine à part le suivi des bugs, je voulais nettoyer un peu plus mantis, mais j'ai été occupé par d'autres projets.
[11:03] Kayaker Magic : Ma blague IRC préférée est : https://xkcd.com/1782/
[11:04] Motoko.Karu @login.digiworldz.com:8002: ^^
[11:06] Andrew Hellershanks : Rien à signaler concernant les changements apportés à la base de code d'OpenSim la semaine dernière. Juste quelques nettoyages mineurs.
[11:07] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai eu un comportement étrange dans la messagerie instantanée hors ligne il y a deux jour, je n'ai pas tout à fait identifié le problème. surtout la messagerie instantanée qui ne se transmet pas correctement, mais puisque cela n'enregistre rien, il n'y a rien d'utile à signaler.
[11:07] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je pense que c'est probablement juste un problème de timing ou de verrouillage car la table est devenue si grande que je suis tenté de commencer à effacer les anciennes entrées.
[11:08] Vincent.Sylvester @hg.zetaworlds.com:8002 : Pour le bug de plantage, j'ai fait un rapport sur mantis car il s'avère qu'il était un peu plus fréquent que je ne le pensais au départ.
[11:09] Vincent.Sylvester @hg.zetaworlds.com:8002 : c'est-à-dire 9012
[11:09] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce sera difficile à localiser, mais un indice, cela a commencé quand la version 179 de mono est sortie ce qui soulève quelques question préoccupantes évidentes.
[11:11] Andrew Hellershanks acquiesce.
[11:11] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il y a eu un autre crash qui faisait référence à quelque chose dans libomv appelé HexNibble, peu importe ce que c'est, ce qui me fait me demander s'il n'y a pas quelque chose avec la conversion des octets en hexadécimal qui se casse.
[11:11] Andrew Hellershanks : oui, les choses se cassent souvent quand on installe des mises à jour :P
[11:12] Vincent.Sylvester @hg.zetaworlds.com:8002 : Revenir en arrière et vérifier certaines des régions qui se sont plantées le plus fréquemment est un dernier recours car revenir en arrière est plutôt ennuyeux et ne résout pas vraiment le problème sous-jacent, que ce soit OpenSim ou mono lui-même.
[11:12] Andrew Hellershanks : Vincent, c'est toujours cassé en 182 ?
[11:12] Vincent.Sylvester @hg.zetaworlds.com:8002 : Oui, d'après ce que je sais.
[11:12] Andrew Hellershanks : ok.
[11:12] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'espérais que cela réglerait le problème et j'ai donc mis à jour immédiatement.
[11:12] Ubit Umarov : un nibble est composé de 4 bits.
[11:14] Vincent.Sylvester @hg.zetaworlds.com:8002 : Tous ces crashs font référence au moteur de script donc j'espère que je finirai par trouver un script qui déclenche cela de manière fiable afin de pouvoir le déboguer.
[11:14] Vincent.Sylvester @hg.zetaworlds.com:8002 : Jusqu'à présent, la pêche dans l'obscurité
[11:14] Vincent.Sylvester @hg.zetaworlds.com:8002 : Juste trop de choses sur ces régions à isoler.
[11:14] Ubit Umarov : on dirait que les try/catch de mono échouent plus souvent maintenant.
[11:16] Vincent.Sylvester @hg.zetaworlds.com:8002 : Si seulement je pouvais trouver comment obtenir des numéros de ligne ou d'autres informations pour pointer plus directement vers le point de défaillance...
[11:16] Vincent.Sylvester @hg.zetaworlds.com:8002 : L'ajout d'une sortie de journal pour enregistrer tous les uuids qu'il rencontre va être vraiment abusif, mais peut être un indice, bien que je n'ai pas été capable de le faire planter sur un mauvais uuid.
[11:18] Andrew Hellershanks:Tu pourrais essayer de l'exécuter en utilisant un débogueur, mais cela pose ses propres problèmes. S'il y a une erreur de segmentation et que tu as un débogage de compilation tu devrais avoir un retour de suivi qui pourrait fournir un point de départ pour savoir où chercher.
[11:18] Ubit Umarov : le bas niveau lève des exceptions si l'entrée a des caractères invalides.
[11:19] Ubit Umarov : cela est appelé à l'intérieur d'un try/catch, donc cela fonctionne comme prévu avec un mono correct
[11:19] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce qui me déconcerte, c'est que j'ai compilé libomv en debug et OpenSim de toute façon, donc ne pas obtenir de numéros de ligne est étrange.
[11:21] Vincent.Sylvester @hg.zetaworlds.com:8002 : Cela ressemble vraiment à un problème de mono, ce qui le rend encore plus urgent à trouver étant donné qu'il peut avoir un impact sur beaucoup de choses.
[11:21] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je suppose qu'à moins de bricoler avec libomv ou de lire le journal de commit mono, je n'irai pas beaucoup plus loin tant que je n'aurai pas trouvé un script qui provoque ce problème de manière fiable.
[11:22] Ubit Umarov : bien et pour mantis 9012 tous ces messages ont certainement plus d'informations avant que la pile ne se vide.
[11:22] Ubit Umarov : comme pour dire QUOI ?
[11:23] Vincent.Sylvester @hg.zetaworlds.com:8002 : La plupart d'entre eux commencent avec la trace de pile juste après la fin d'un OAR ou le nettoyage du cache flotsam, mais pas d'échec ou d'erreur, la trace de pile est immédiate.
[11:24] Ubit Umarov : bon, la trace de pile ne veut rien dire sans cause.
[11:26] Ubit Umarov : au fait, listtofloat vérifie les uuids.
[11:26] Ubit Umarov : parce que quelqu'un a décidé qu'un uuid peut représenter un nombre flottant.
[11:26] Ubit Umarov : ou un entier exprimé en tant que float.
[11:27] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai parcouru le journal de la région qui se plante le plus, cela arrive toujours juste après l'exécution du datasnapshot.
[11:27] Andrew Hellershanks : quelqu'un a décidé qu'un uuid peut correspondre à un nombre flottant ?? On dirait que quelqu'un a eu des idées très étranges.
[11:28] Ubit Umarov : les clés valides semblent être analysées comme des entiers puis converties en float,
if (item is LSL_Key)
{
string s = item.ToString();
if(UUID.TryParse(s, out UUID uuidt))
return Convert.ToDouble(new LSL_Integer(s).value);
// on ne peut pas le faire car une chaîne de caractères est aussi une LSL_Key pour le moment :(
// else
// return 0;
}
[11:28] Ubit Umarov : les commentaires sont là depuis " toujours ".
[11:29] Ubit Umarov : je suppose que c'est parce que les clés sont enveloppées dans une chaîne, donc les gens ont des chaînes rapportées comme des clés, donc c'était nécessaire ???
[11:29] Andrew Hellershanks : Cela doit venir en partie d'autres endroits où il y a peu de différence entre une clé et une chaîne.
[11:29] Ubit Umarov : aucune idée :)
[11:30] Ubit Umarov : problèmes de casting automatique
[11:30] Ubit Umarov : possible
[11:30] Andrew Hellershanks : Bonjour, Selby.
[11:30] Selby.Evans @grid.kitely.com:8002 : bonjour -- Internet ne fonctionnait pas jusqu'à maintenant.
[11:30] Ubit Umarov : mais bon, c'est comme ça depuis des lustres... et même c'est possible que cela fasse comme SL en réalité.
[11:30] Ubit Umarov: salut bienvenue
[11:32] Kayaker Magic : Heureux que ton Internet soit revenu Selby !
[11:32] Andrew Hellershanks : Au moins, il n'a pas attendu la fin de la réunion pour revenir :)
[11:33] Vincent.Sylvester @hg.zetaworlds.com:8002 : Celui-ci a planté au niveau de
at OpenSim.Server.Handlers.Simulation.Utils:GetParams <0x001c3> at OpenSim.Server.Handlers.Simulation.AgentSimpleHandler:ProcessRequest <0x0014f>
[11:34] Ubit Umarov : test sur un script
[11:34] Ubit Umarov:
string a = "adb23jjd";
llOwnerSay((string)osIsUUID(a));
[11:34] Ubit Umarov : avec plusieurs variantes sur "a".
[11:34] Vincent.Sylvester @hg.zetaworlds.com:8002 : Oui, j'ai essayé une tonne de cela, mais jusqu'à présent rien n'a planté.
[11:35] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce qui semble vraiment commun, c'est que les plantages se produisent après l'exécution de DataSnapShot.
[11:35] Vincent.Sylvester @hg.zetaworlds.com:8002 : Dans trois régions, il y a eu plusieurs crashs, toujours juste après cela.
[11:35] Ubit Umarov : ce truc os est juste un tryparse direct :
[11:35] Ubit Umarov:
public LSL_Integer osIsUUID(string thing)
{
CheckThreatLevel();
return UUID.TryParse(thing, out UUID test) ? 1 : 0;
}
[11:36] Vincent.Sylvester @hg.zetaworlds.com:8002:
at <unknown> <0xffffffff>
at OpenSim.Region.ScriptEngine.Shared.ScriptBase.ScriptBaseClass:llSetRot <0x00061>
at System.Object:CheckSun() <0x009c2>
at System.Object:default timer <0x00452>
[11:36] Ubit Umarov: setrot??
[11:36] Vincent.Sylvester @hg.zetaworlds.com:8002 : Oui, je ne l'invente pas.
[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002 :
at OpenSim.Region.ScriptEngine.Yengine.XMRInstAbstract:CallSEH <0x00236>
[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il est également assez courant que
[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002 : Des trucs vraiment étranges
[11:37] Andrew Hellershanks : C'est très étrange.
[11:37] Ubit Umarov : es-tu sûr que ton cpu n'a pas un trou sur le fpu ?
[11:37] Ubit Umarov : :)
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je compte 154 stacktraces gérés dans ces régions.
[11:38] Ubit Umarov : le dernier point n'est pas lié à la question.
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002 : Possible, qui sait ce que le bitflip fait là, mais si fréquemment juste après Datasnapshot, c'est un indice... J'espère
[11:40] Ubit Umarov : eh bien, ce n'est pas le cas. J'ai une région qui le fait, sans aucun problème.
[11:40] Ubit Umarov : eh bien, ce n'est pas le cas. J'ai une région qui le fait, sans aucun problème.
[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce ne sont pas toutes les régions qui plantent, sur 96, seules 21 plantent régulièrement maintenant.
[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002 : un peu plus, un peu moins
[11:41] Ubit Umarov : certaines choses comme les références nulles se produisent un peu plus maintenant, c'est lié aux présences dans la scène, c'est à dire les avatars.
[11:41] Ubit Umarov : depuis que j'ai ajouté la nécessité de les supprimer explicitement.
[11:42] Ubit Umarov : dans le passé, ils restaient simplement en mémoire après le départ de l'avatar, donc il n'y avait pas de réfs null.
[11:43] Ubit Umarov : donc beaucoup de code est simplement cassé, c'est à dire qu'il a été fait sans test de présence réelle de l'avatar, donc cela produit ... quelque chose sans erreur.
[11:43] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je suppose que je devrais réinstaller mono et voir si ça ne se produit plus, même si ça pose des problèmes, pour savoir si c'est juste ça ou OpenSim.
[11:43] Vincent.Sylvester @hg.zetaworlds.com:8002 : Bien que je doute que ce soit OpenSim
[11:43] Ubit Umarov : avec un peu de chance, il donne un avertissement et continue.
[11:43] Ubit Umarov : la question de l'uuid n'est pas au niveau d'opensim.
[11:44] Ubit Umarov : comme je l'ai dit, c'est une erreur de mono, qui ne fait pas un try/catch correct.
[11:44] Ubit Umarov : ou du moins c'est ce qu'il semble.
[11:44] Ubit Umarov : je ne peux pas faire de repo
[11:44] Ubit Umarov : ( j'ai seulement mono 122 )
[11:45] Vincent.Sylvester @hg.zetaworlds.com:8002: Problem is of course rolling back and then not seeing the issue doesn't solve the problem, means crawling through mono commit log and finding what might be the cause, which sounds like fun... [11:46] Andrew Hellershanks: I have 182. [11:46] Vincent.Sylvester @hg.zetaworlds.com:8002: Heh maybe need to put the try catch inside another try catch [11:46] Andrew Hellershanks: :) [11:47] Vincent.Sylvester @hg.zetaworlds.com:8002: Really weird, always datasnapshot, crash on some lsl function totally unrelated [11:47] Ubit Umarov: well to know WHAT did mono see could help [11:47] Vincent.Sylvester @hg.zetaworlds.com:8002: I dread to even go to the commit log fearing for how much I will find there to go through [11:48] Vincent.Sylvester @hg.zetaworlds.com:8002: Gonna need like ten clones to give that a code review [11:48] Ubit Umarov: mono guys are now like opensim ones.. do commits like "several bugs fixes" :p [11:49] Ubit Umarov: "want to know more?" [11:49] Andrew Hellershanks: :) [11:49] Ubit Umarov: see the commit [11:49] Vincent.Sylvester @hg.zetaworlds.com:8002: Not to mention can't actually really tell what went into the release, just guess basically [11:49] Ubit Umarov: well thye only did publish the release notes for 174 not 179 [11:50] Vincent.Sylvester @hg.zetaworlds.com:8002: This going to be a fun bug... [11:50] Andrew Hellershanks: Vincent, you should be able to tell that based on the tags and dates of release. [11:51] Ubit Umarov: seems there is a even on Metro close [11:51] Ubit Umarov: but like all modern reporters.. NO DATE on the news :p [11:51] Ubit Umarov: at least i could not see it [11:52] Vincent.Sylvester @hg.zetaworlds.com:8002: Sad to see them go like this [11:52] Vincent.Sylvester @hg.zetaworlds.com:8002: Such a constant just vanishing [11:52] Ubit Umarov: " [11:52] Ubit Umarov: The play is titled “The Art Giantess Is The Work: Thea von Harbou,” and will be performed in English, with German subtitles. It will start at 1 p.m. Pacific time, or 10 p.m. German time on the Futurelab region.
The hypergrid address is metro.land:8002:futurelab. [11:52] Ubit Umarov: " [11:52] Ubit Umarov: see any date? [11:53] Vincent.Sylvester @hg.zetaworlds.com:8002: Best show up every day to make sure [11:54] Ubit Umarov: well this is so typical of news on the net.. jezz [11:54] Andrew Hellershanks: The web page says the grid will close on June 30. [11:54] Ubit Umarov: yes june 30 is a guess... but if it closed.. can't be :P [11:55] Ubit Umarov: other guess is june 27.. the news date ( by miracle there >) [11:55] Ubit Umarov: but guess june 30 is the date [11:56] Ubit Umarov: well sounds a nice event... so.. [11:56] Ubit Umarov: https://www.hypergridbusiness.com/2022/06/new-play-premieres-on-metropolis-grid/ [11:57] Ubit Umarov: well that hypergrid site sees a mess now [11:58] Ubit Umarov: was looking to opensim news, now looking to Home i see "news" abotu opensim, not there [11:58] Andrew Hellershanks: An image further down that page indicates the play premieres on the 30th. [11:58] Andrew Hellershanks: Not that unusual a situation for theatre plays. Open and close on the same day. ;) [11:58] Ubit Umarov: :) [11:58] Ubit Umarov: well this is on hypergrid home, not news [11:59] Ubit Umarov: https://www.hypergridbusiness.com/2022/06/diva-distro-seals-vulnerability-grids-need-to-update/ [11:59] Andrew Hellershanks: The hour is almost up once again. Any other questions/comments before we wrap up todays gathering? [12:01] Ubit Umarov: seems it was a stack overflow, due to un guarded recurrency calls [12:01] Ubit Umarov: think i did remove one of such tech uses fro opensim [12:02] Andrew Hellershanks: Thanks for mentioning that article. Important information for anyone using Diva Wifi. [12:03] Ubit Umarov: recurrent calls are nice way to doe some code, but very easy to go wrong, specialling if using user provided arguments [12:03] Ubit Umarov: ..specialy .. [12:03] Kayaker Magic: Duty calls, I need to run. [12:04] Ubit Umarov: tp is faster [12:04] Ubit Umarov: ) [12:04] Ubit Umarov: when it does not fail... ofc [12:04] Selby.Evans @grid.kitely.com:8002: bye all [12:04] Ubit Umarov: cya [12:05] Andrew Hellershanks: Bye, Kayaker and Selby. [12:05] Motoko.Karu @login.digiworldz.com:8002: bye [12:06] Andrew Hellershanks: If there is nothing more for today I'll call this meeting to a close. [12:06] Andrew Hellershanks: Thank you all for coming. See you again next week.