Introduction

• Traduction de la bande dessinée proposée par Kayaker :

 2004 : Notre équipe reste en contact via 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  : 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 : ^^

[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.

Messagerie Instantanée

[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.

Bug de plantage : Mantis 9012

• Mantis 9012 : http://opensimulator.org/mantis/view.php?id=9012
• Adresse du journal d'une région : <chemin du simulateur><simulateur>/bin/OpenSim.log
• Datasnapshot(en) : Le module DataSnapshot est un IRegionModule qui prend les données de diverses parties de la scène OpenSimulator et sort un fichier XML au format personnalisé. Vous pouvez ainsi créer des services Web à partir des données de sortie. Considérez-le comme analogue à une "API de recherche", bien qu'il ne soit pas limité à la simple recherche.

[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[1] 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[2] 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 alternative ultime parce que c'est plutôt laborieux et cela 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 [3]?

[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[4] est composé de 4 bits.

[11:14] Vincent.Sylvester @hg.zetaworlds.com:8002  : Tous ces crashs font référence au moteur de script [5][6] 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, j'avance dans le noir.

[11:14] Vincent.Sylvester @hg.zetaworlds.com:8002  : Il y a simplement trop de choses à isoler sur ces régions.

[11:14] Ubit Umarov  : on dirait que les try/catch [7] 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 [8] 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[9], 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 [https://fr.wikipedia.org/wiki/Langage_de_programmation_de_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 [10] de 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  : bon 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 [11] 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: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.

Analyse du code de listtofloat

[11:26] Ubit Umarov  : au fait, listtofloat [12](?) vérifie les uuids.

[11:26] Ubit Umarov  : parce que quelqu'un a décidé qu'un uuid peut représenter un float[13].

[11:26] Ubit Umarov  : ou un entier[14] exprimé en tant que float.

[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 :)

Bug de plantage (suite)

[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[15] 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?? [16]

[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[17] n'a pas un trou sur le fpu [18]?

[11:37] Ubit Umarov  : :)

[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002  : Je compte 154 stacktraces (traces de pile) 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 (inversion des bits) 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] 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  : Le problème est bien sûr de revenir en arrière et de ne pas trouver le problème ne résout pas le souci, ce qui signifie qu'il faut fouiler dans le journal des commits de mono et trouver ce qui pourrait être la cause, ce qui semble être une meilleure idée...

[11:46] Andrew Hellershanks : j'ai la 182.

[11:46] Vincent.Sylvester @hg.zetaworlds.com:8002  : Heh il faudrait peut-être mettre le catch try à l'intérieur d'un autre catch try.

[11:46] Andrew Hellershanks : :)

[11:47] Vincent.Sylvester @hg.zetaworlds.com:8002  : Vraiment bizarre, toujours un datasnapshot, un crash sur une fonction lsl[19] sans aucun rapport.

[11:47] Ubit Umarov  : savoir CE QUE mono a détecté pourrait aider.

[11:47] Vincent.Sylvester @hg.zetaworlds.com:8002  : Je redoute même d'aller dans le journal des commits, craignant tout ce que je vais y trouver et parcourir.

[11:48] Vincent.Sylvester @hg.zetaworlds.com:8002  : Je vais avoir besoin de dix clones pour faire une analyse du code.

[11:48] Ubit Umarov  : les gars de mono sont maintenant comme ceux d'opensim... ils font des commits du genre "plusieurs corrections de bugs" :p

[11:49] Ubit Umarov  : "tu veux en savoir plus ?"

[11:49] Andrew Hellershanks  : :)

[11:49] Ubit Umarov  : voir le commit

[11:49] Vincent.Sylvester @hg.zetaworlds.com:8002  : Sans parler du fait qu'on ne peut pas vraiment dire ce qui est entré dans la version, on ne fait que deviner, en gros.

[11:49] Ubit Umarov  : ils n'ont publié les notes de version que pour la 174 et pas pour la 179.

[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002  : Cela va être un bug sympathique...

[11:50] Andrew Hellershanks : Vincent, tu devrais être capable de dire cela en se basant sur les tags et les dates de release.

Évènement sur Metro

[11:51] Ubit Umarov  : il semble qu'il y ait un événement sur Metro [20] bientôt.

[11:51] Ubit Umarov  : mais comme tous les reporters modernes... PAS DE DATE sur l'information :p

[11:51] Ubit Umarov  : en tout cas, je ne l'ai pas vue.

[11:52] Vincent.Sylvester @hg.zetaworlds.com:8002  : Triste de les voir partir comme ça

[11:52] Vincent.Sylvester @hg.zetaworlds.com:8002  : Une telle présence qui disparaît comme ça

[11:52] Ubit Umarov : "

[11:52] Ubit Umarov  : La pièce s'intitule " The Art Giantess Is The Work : Thea von Harbou ", et sera jouée en anglais, avec des sous-titres allemands. Elle commencera à 13 heures, heure du Pacifique, ou à 22 heures, heure allemande, sur la région Futurelab.

L'adresse hypergrid est metro.land:8002:futurelab.

[11:52] Ubit Umarov : "

[11:52] Ubit Umarov  : vous voyez une date ?

[11:53] Vincent.Sylvester @hg.zetaworlds.com:8002  : Il vaut mieux se montrer tous les jours pour être sûr

[11:54] Ubit Umarov  : c'est typique des nouvelles sur le net... jezz

[11:54] Andrew Hellershanks  : La page web indique que la grille sera fermée le 30 juin.

[11:54] Ubit Umarov  : oui, le 30 juin est une supposition... mais si elle est fermée... cela ne peut pas être :P

[11:55] Ubit Umarov  : une autre supposition est le 27 juin... la date de la nouvelle ( par miracle là >)

[11:55] Ubit Umarov  : mais je pense que la date est le 30 juin.

[11:56] Ubit Umarov  : Bien, cela semble être un bel événement... donc...

[11:56] Ubit Umarov  : https://www.hypergridbusiness.com/2022/06/new-play-premieres-on-metropolis-grid/

[11:57] Ubit Umarov  : Le site hypergrid est en désordre maintenant.

[11:58] Ubit Umarov  : je regardais les nouvelles d'opensim, maintenant je regarde sur Home et je vois des "nouvelles" sur opensim, ce n'est là.

[11:58] Andrew Hellershanks  : Une image plus bas sur cette page indique que la première de la pièce aura lieu le 30.

[11:58] Andrew Hellershanks  : Ce n'est pas une situation habituelle pour une pièce de théâtre. Ouverture et fermeture le même jour ;)

[11:58] Ubit Umarov  : :)

[11:58] Ubit Umarov  : c'est sur l'accueil hypergrid , pas sur nouvelles.

Diva Distro corrige une vulnérabilité, les grilles doivent être mis à jour

[11:59] Ubit Umarov : https://www.hypergridbusiness.com/2022/06/diva-distro-seals-vulnerability-grids-need-to-update/

[12:01] Ubit Umarov  : Il semble que ce soit un débordement de pile, dû à des appels récurrents non conservés.

[12:01] Ubit Umarov  : je pense que j'ai enlevé une de ces utilisations techniques d'opensim.

[12:02] Andrew Hellershanks  : Merci d'avoir mentionné cet article. Information importante pour tous ceux qui utilisent Diva Wifi.

[12:03] Ubit Umarov  : les appels récurrents sont une bonne façon de coder, mais il est très facile de se tromper, en particulier si l'on utilise des paramètres fournis par l'utilisateur.

[12:03] Ubit Umarov  : ... spécialement...

Conclusion

[11:59] Andrew Hellershanks  : L'heure est presque terminée une fois de plus. D'autres questions/commentaires avant de conclure la réunion d'aujourd'hui ?

[12:03] Kayaker Magic  : Le devoir m'appelle, je dois courir.

[12:04] Ubit Umarov  : se téléporter est plus rapide.

[12:04] Ubit Umarov  : )

[12:04] Ubit Umarov  : quand ça ne plante pas... bien sûr !

[12:04] Selby.Evans @grid.kitely.com:8002  : au revoir tout le monde

[12:04] Ubit Umarov  : salut !

[12:05] Andrew Hellershanks  : Au revoir, Kayaker et Selby.

[12:05] Motoko.Karu @login.digiworldz.com  : au revoir.

[12:06] Andrew Hellershanks  : S'il n'y a rien de plus pour aujourd'hui, je vais mettre fin à cette réunion.

[12:06] Andrew Hellershanks  : Merci à tous d'être venus. Nous nous reverrons la semaine prochaine.