Réunion du 12-07-2022
Source : http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2022-07-12
Introduction
[11:04] Ubit Umarov : ahh le chat d'andrew s'est souvenu de la réunion.
[11:04] Andrew Hellershanks : Je suis au téléphone,
[11:04] Misterblue Waves : nous sommes montés jusqu'à 48c l'été dernier -- les plantes n'ont pas bien résisté.
[11:05] Ubit Umarov : Ohh ok on va taper doucement
[11:05] Ubit Umarov : ouais mais 48 ici c'est rare... comme 45 ans rare.
Fsassets : instances multiples
[11:06] Ubit Umarov : à propos d'opensim, encore une fois pas grand chose.
[11:06] Vincent.Sylvester @hg.zetaworlds.com:8002 : Deux changements la semaine dernière, un autre nettoyage de libomv et un correctif pour fsassets qui n'utilise pas correctement ses dossiers. J'ai ramené mono à 122 vendredi et j'attends maintenant ce que cela fait aux régions. Jusqu'à présent, je n'ai pas entendu parler de nouveaux crashs, mais je vais devoir le laisser un peu pour être sûr. FS a sorti une nouvelle beta avec le support du statut de la grille rss maintenant supporté dans OpenSim.
[11:06] Misterblue Waves : même chose pour nous -- il est rare de dépasser les 100F.
[11:06] Ubit Umarov : j'ai fait un petit commit lié à un flag fsassets.
[11:07] Ubit Umarov : ou une option, en fait pas si bonne...
[11:07] Ubit Umarov : pour exécuter plusieurs instances de fsassets, cela ne fonctionnera pas.
[11:07] Ubit Umarov : à moins d'avoir un disque réseau comme stockage.
[11:07] Andrew Hellershanks: .0
[11:08] Ubit Umarov : fs ne fait qu'écrire des choses sur un disque, il n'a aucune idée de ce que sont les instances multiples.
[11:08] Ubit Umarov : les métadonnées dépendent de mysql qui fait le truc du multi serveur, ça ne semble pas très bon non plus.
[11:09] Ubit Umarov : donc, pas si utile que ça cette option...
[11:09] Ubit Umarov : hmm quel était l'autre ? libomv ?
[11:10] Ubit Umarov : hmm je suppose que c'est aussi une chose mineure.
[11:10] Vincent.Sylvester @hg.zetaworlds.com:8002 : Est-ce que le truc de fsassets est principalement un verrouillage de fichier ou quel est le problème ?
[11:11] Ubit Umarov : ah oui... j'utilisais une exception c# générique pour signaler une mauvaise chaîne de caractères lors de l'analyse.
[11:12] Kayaker Magic : Un problème avec plusieurs fsassets est qu'il y a peu de chance que deux d'entre eux génèrent le même UUID en même temps.
[11:12] Ubit Umarov : changé en FormatException pour correspondre à ce que .net guid fait.
[11:12] Ubit Umarov : fs ne génère pas d'uuids.
[11:12] Kayaker Magic : OK, alors plusieurs Robusts.
[11:13] Ubit Umarov : le problème avec des robusts multiples est que vous avez besoin d'un stockage partagé.
[11:13] Ubit Umarov : fsasset n'est pas prévu pour cela.
[11:14] Ubit Umarov : chaque instance va juste lire et écrire depuis son propre disque.
[11:14] Ubit Umarov : quelque chose qui ne fonctionnera pas du tout, à moins que ce soit un disque réseau partagé spécial.
[11:14] Ubit Umarov : ou on peut faire tourner tout cela sur la même machine, ce qui n'est pas très utile non plus.
[11:15] Ubit Umarov : sur ce point fsassets est pire que les assets normaux, qui au moins dépendent uniquement de mysql/maria.
[11:16] Ubit Umarov : les multi-instances fsassets qui ont fonctionné, ont été installée séparant quelques bits de l'UUID de l'asset.
[11:16] Ubit Umarov : a t-on toujours du code pour cela, je n'en suis pas sûr.
[11:17] Ubit Umarov : bien sûr, cela ne fonctionne pas très bien avec le type guid "aléatoire" que nous utilisons.
[11:17] Ubit Umarov : pas si aléatoire que cela
[11:18] Ubit Umarov : c'est pourquoi osgrid fonctionne avec ses propres assets propriétaires...
[11:18] Ubit Umarov : j'utilisais une variante de fsassets, qui faisait aussi de la fumée si on utilisait plus d'une instance.
[11:18] Ubit Umarov : maintenant j'utilise quelque chose d'autre.
[11:19] Ubit Umarov : bien sûr, il n'y a pas de problème si vous avez une bonne machine NAS et un réseau 100Gbit ;)
[11:19] Vincent.Sylvester @hg.zetaworlds.com:8002 : Etant donné la simplicité de ce que cela doit faire au final, il est plus facile d'écrire avec quelque chose d'autre qui supporte le verrouillage des fichiers de manière appropriée, je suppose. Idéalement directement en C pour obtenir la plus grande vitesse.
[11:20] Ubit Umarov : le verrouillage des fichiers semble échouer sous linux.
[11:21] Ubit Umarov : ce code fsassets exécute aussi plusieurs instances sur un seul robust...
[11:21] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ce n'est pas intégré, donc le langage ou le code doit le gérer lui-même.
[11:21] Ubit Umarov : une comme instance principale des assets, les autres comme esclaves qui s'y connectent.
[11:21] Misterblue Waves : les GUIDs ne sont pas assez aléatoires ou le contenu n'est pas unique ?
[11:22] Ubit Umarov : il y avait toujours un problème de verrouillage, car plusieurs threads de maintenance pouvaient être déclenchés dans ce cas...
[11:22] Ubit Umarov : ça devrait être ok maintenant...
[11:23] Ubit Umarov : mes commentaires ne concernaient que les personnes qui essayaient de faire tourner plusieurs instances de service d'assets sur différentes machines...
[11:23] Ubit Umarov : comme je l'ai dit, ça ne marche pas, sauf s'ils utilisent un disque partagé sur le réseau.
[11:24] Vincent.Sylvester @hg.zetaworlds.com:8002 : Ou quelque chose qui émule le comportement de ce type de disque, je suppose.
[11:24] Ubit Umarov : Oui
[11:24] Ubit Umarov : alors bien sûr il faut comparer la latence ajoutée à la latence d'un seul...
[11:25] Ubit Umarov : sur ce point, les caches de région et de viewers sont fondamentaux.
[11:26] Ubit Umarov : dans les cas normaux, seuls les caches des régions devraient être utilisés.
[11:26] Ubit Umarov : dans le cas d'utilisateurs qui passent le plus de temps sur quelques régions, aussi les caches de viewer.
[11:27] Vincent.Sylvester @hg.zetaworlds.com:8002 : D'après ce que j'enregistre sur disk io, je vois rarement plus de quelques mbits lorsque les assets sont déplacés, ce n'est donc pas une charge importante pour atteindre des centaines de gigaoctets.
[11:27] Vincent.Sylvester @hg.zetaworlds.com:8002 : Le plus gros problème est de sauvegarder des millions de fichiers dans des milliers de répertoires.
[11:28] Ubit Umarov : beaucoup de gens ont même oublié que fsassets utilise mysql et des fichiers disques.
[11:28] Ubit Umarov : et ont perdu les fichiers du disque :(
[11:28] Kayaker Magic : oops ! Je déteste quand ça arrive !
[11:28] Misterblue Waves : quelque chose comme S3 serait mieux -- pas AWS mais l'une des interfaces compatibles des hash buckets modernes.
[11:28] Ubit Umarov : c'est malheureusement arrivé plusieurs fois.
Les bases de données
[11:29] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il devrait probablement utiliser encore plus de sql pour cela, pour des choses comme les notecards qui enregistrent leur description dans des assets ce qui implique que, même si elles sont vides, le hash est toujours différent, ce qui crée des tonnes d'assets de notecards vides.
[11:30] Vincent.Sylvester @hg.zetaworlds.com:8002 : AWS, c'est de la camelote hors de prix, vous paierez plus cher pour l'utiliser que pour un simple serveur matériel décent et quand ils perdent vos données, vous êtes foutu.
[11:30] Ubit Umarov : plusieurs grandes grilles fonctionnent bien.
[11:30] Ubit Umarov : quelques mb avec leurs propres solutions
[11:31] Ubit Umarov : Je n'ai jamais aimé fsassets.
[11:31] Misterblue Waves : d'accord pour AWS, mais beaucoup d'autres fournisseurs proposent un stockage compatible S3 (DigitalOcean, ...)
[11:31] Ubit Umarov : bien sûr mysql est peut-être un mauvais choix.
[11:31] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je suis en train de jouer avec l'idée d'explorer toutes notecards à la recherche de lignes vides et de les détruire ou de mettre leur hash à une seule place.
[11:31] Ubit Umarov : inworldz a utilisé un autre moteur de base de données, si je me souviens bien.
[11:32] Ubit Umarov : un truc plus direct de type clé et valeur.
[11:32] Ubit Umarov : je pense qu'il n'y a même pas de sql.
[11:32] Vincent.Sylvester @hg.zetaworlds.com:8002 : Pour certaines choses, quelques structures de données dans OpenSim, des choses comme mongodb fonctionneraient, potentiellement mieux que sql, mais alors on a un autre système de base de données à maintenir et à gérer aussi, donc un compromis...
[11:33] Vincent.Sylvester @hg.zetaworlds.com:8002 : Pour les données des avatars et des groupes, cela pourrait être plus rapide, mais cela implique un tout nouveau connecteur de base de données, etc.
[11:33] Vincent.Sylvester @hg.zetaworlds.com:8002 : c'est déjà une douleur de maintenir ceux que nous avons
[11:33] Ubit Umarov : Nos bases de données sont un désastre.
[11:33] Vincent.Sylvester @hg.zetaworlds.com:8002 : Certaines, pas toutes
[11:33] Ubit Umarov : un bon exemple de comment rendre les choses aussi lentes que possible.
[11:33] Ubit Umarov : region db ... duhhh quel gaspillage
[11:34] Vincent.Sylvester @hg.zetaworlds.com:8002 : L'inventaire pourrait également bénéficier d'une base de données de type document plutôt que de grandes tables.
[11:34] Vincent.Sylvester @hg.zetaworlds.com:8002 : Tout ce qui est lié à un seul utilisateur ou uuid, je suppose.
[11:35] Vincent.Sylvester @hg.zetaworlds.com:8002 : Inutile pour les assets, il faut une vraie table avec des clés et des index à ce niveau.
[11:35] Vincent.Sylvester @hg.zetaworlds.com:8002 : En y réfléchissant, je voulais vérifier si le jeu de caractères et la collation avaient un impact sur les performances des groupes, comme c'est le cas pour les données de griduser.
[11:35] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il semble que le regroupement de ces éléments soit un échec dans mariadb.
[11:36] Vincent.Sylvester @hg.zetaworlds.com:8002 : Cela nécessite des éléments uniformes pour accélérer inner join.
[11:36] Ubit Umarov : il semble que mariadb est défaillante pour tout ce qui est volumineux.
[11:36] Ubit Umarov : même mysql
[11:36] Ubit Umarov : seuls quelques forks de mysql tiennent, m'a-t-on dit.
[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002 : Le développement s'est accéléré ces derniers temps, alors peut-être que cela va changer positivement à l'avenir.
[11:37] Misterblue Waves : J'ai utilisé MariaDB avec succès pour de petits déploiements (c'est ce que j'utilise pour mes régions installée avec Docker).
Problème de script gèle une région
[11:36] Kayaker Magic : J'ai quelques trucs mis en place pour OpenSim Fest, et une des régions a cessé de fonctionner. Les scripts ont gelé, je n'étais pas autorisé à compiler mes propres scripts ou à recharger plus d'objets. Shelenn m'a dit que c'était dû à un bug d'OpenSim que Ubit connaissait déjà. Quel bug était-ce ?
[11:37] Ubit Umarov : aucune idée
[11:37] Ubit Umarov : ils utilisent une chose appelée opensim-ngc.
[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002 : Si vous surchargez une région avec trop de mises à jour de scènes, la file d'attente pour cela se remplit et le traitement s'arrête complètement.
[11:37] Ubit Umarov : qui, bien sûr, prétend être meilleur que le noyau.
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002 : Il n'y a pas grand chose à faire à ce niveau.
[11:38] Ubit Umarov : donc tu dois leur demander :)
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002 : la file d'attente de mise à jour des scènes a une taille fixe, une fois pleine, elle est pleine et meurt.
[11:38] Ubit Umarov : Je ne me souviens pas d'un tel problème...
[11:39] Vincent.Sylvester @hg.zetaworlds.com:8002 : J'ai vu cela plusieurs fois, on m'a toujours dit de supprimer certains scripts lourds, des timers et autres, et il n'y a plus de problèmes.
[11:39] Ubit Umarov : quelles mises à jour de la scène ??
[11:39] Vincent.Sylvester @hg.zetaworlds.com:8002 : Celles qui sont générées par les scripts, les avatars, etc. J'ai oublié le nom exact, mais ce ne sont pas les scripts qui meurent, ce sont les mises à jour des scènes.
[11:39] Ubit Umarov : tu imagines encore des choses vincent :p
[11:39] Ubit Umarov : la file d'attente des événements ?
[11:40] Ubit Umarov : ces auto limites... n'arrêtent pas les choses.
[11:40] Ubit Umarov : bien sûr, un script peut toujours geler une région de plusieurs manières...
[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002 : Tu peux tester si c'est ça en tapant des commandes dans la console, si ça échoue avec une erreur, peu importe ce que tu tapes, tu sais que c'est bloqué.
[11:41] Vincent.Sylvester @hg.zetaworlds.com:8002 : La réduction de la charge des scripts résout généralement ce problème.
[11:41] Kayaker Magic : Après qu'ils l'aient "corrigé", j'ai pu ajouter plus d'objets scriptés.
[11:41] Ubit Umarov : Je ne me souviens pas de ce problème sur le noyau... possible... mais je ne m'en souviens pas...
[11:42] Ubit Umarov : Je veux dire un problème spécifique.
[11:42] Vincent.Sylvester @hg.zetaworlds.com:8002 : Tu dois charger les régions assez lourdement pour que cela se produise. La plupart restent bien en dessous de cela ou écrivent des scripts qui ne provoquent pas autant de mises à jour.
[11:43] Ubit Umarov : Je me souviens de régions complètement à plat.
[11:43] Vincent.Sylvester @hg.zetaworlds.com:8002 : Cela n'arrive pas assez souvent pour justifier un examen approfondi. Il est plus facile d'écrire de meilleurs scripts.
[11:43] Ubit Markov : simplement à cause d'un simple script de LED.
[11:43] Ubit Umarov : nous ne pouvions plus nous tp dans la région ou les régions voisines :)
[11:44] Ubit Umarov : un script similaire fera toujours la même chose.
[11:44] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je n'ai vu cela que sur une région avec environ 90k prims et plus de 8000 scripts.
[11:44] Ubit Umarov : changer l'éclat ou la couleur etc. d'une prim est une mise à jour complète.
[11:44] Ubit Umarov : cette région avait peut-être 1000 LEDs :)
[11:45] Ubit Umarov : nous avons tous vu ce problème à Noël... avec de mauvaises lumières de Noël.
[11:45] Vincent.Sylvester @hg.zetaworlds.com:8002 : On pourrait probablement trouver la file d'attente et déterminer quelle est la taille maximale et ajouter un débogage pour alerter lorsqu'elle est proche du plein.
[11:45] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je n'ai jamais regardé où c'était.
[11:46] Ubit Umarov : tu es encore là avec une file d'attente... quelle file d'attente ??
[11:46] Ubit Umarov : il y en a plusieurs.
[11:46] Kayaker Magic : Après avoir vu quelques mauvais scripts de lumières de Noël, j'ai écrit des scripts ZERO LAG qui utilisent des animations de textures pour clignoter.
[11:46] Ubit Umarov : et aucun problème.
[11:47] Ubit Umarov : oui le clignotement doit être fait avec une animation de texture intelligente.
[11:48] Vincent.Sylvester @hg.zetaworlds.com:8002 : Quand un script déplace une prim, cela est ajouté à une file d'attente comme une mise à jour de la scène, généralement traitée presque immédiatement, sauf si on a beaucoup de ces mises à jour.
[11:48] Ubit Umarov : il s'agit d'un vieux problème, également chez SL.
[11:48] Vincent.Sylvester @hg.zetaworlds.com:8002 : Je ne suis pas sûr de l'endroit du code où cela se trouve, je ne l'ai jamais beaucoup étudié.
[11:48] Ubit Umarov : lludp met à jour la queue par utilisateur ??
[11:49] Ubit Umarov : c'est lourd, c'est un problème majeur actuellement.
[11:49] Vincent.Sylvester @hg.zetaworlds.com:8002: Possible, all I know is it's something that fills up and then overloads stopping update processing because you can still walk around and chat, but scripts appear as if they are stopped [11:49] Ubit Umarov: they do not fill up [11:49] Ubit Umarov: ma fill your machine ram :p [11:50] Vincent.Sylvester @hg.zetaworlds.com:8002: As it doesn't happen immediately and only when more scripts and people are on the region tells me it's some processing for the updates done on scene [11:50] Vincent.Sylvester @hg.zetaworlds.com:8002: Usually just writing better scripts and reducing the load fixes this [11:50] Ubit Umarov: scripts need to be good [11:51] Vincent.Sylvester @hg.zetaworlds.com:8002: You can have a region with hundreds of thousands of prims and one script that kills it [11:51] Ubit Umarov: a single bad script can stop a region, as i said [11:51] Ubit Umarov: .. still... [11:51] Ubit Umarov: specially using some OSSL there should had never need added [11:51] Ubit Umarov: details.. [11:51] Kayaker Magic: A bad programmer can write FORTRAN in any language;. [11:52] Vincent.Sylvester @hg.zetaworlds.com:8002: Writing stuff for light changing and animations can be insanely heavy [11:52] Andrew Hellershanks: Hello, everyone. Finally off the phone call. :P Last part of it was giving the person directions to the place they were driving to as it turned out they were headed north when they should have been going south. [11:52] Vincent.Sylvester @hg.zetaworlds.com:8002: Still writing on danceballs and other lighting stuff I check what cpu does, sometimes a poorly written line gives me 100% cpu heh [11:53] Andrew Hellershanks: Vincent, doesn't take much to do that. [11:53] Vincent.Sylvester @hg.zetaworlds.com:8002: In the same tune if you can figure out what it does internally you can change a color 60 times a second without much load [11:54] Andrew Hellershanks: I have been helping people do some X and Y engine compatibility tests this past week. Their scripts trigger an exception in YEngine during compilation. Not sure what is causing that. Runtime I was getting an out of heap exception. [11:55] Vincent.Sylvester @hg.zetaworlds.com:8002: lol ouch [11:55] Vincent.Sylvester @hg.zetaworlds.com:8002: That takes some serious effort [11:55] Andrew Hellershanks: Looking at the OS code I found some ini settings to change heap sizes and that solved the heap issue. [11:55] Andrew Hellershanks: Still no idea about the compile time error. [11:55] Ubit Umarov: ohh really? [11:55] Ubit Umarov: mab next time RTFM ? [11:55] Ubit Umarov: maybe.. :p [11:56] Andrew Hellershanks: Ubit, yes. There are ini settings for setting stack and heap sizes in YEngine but they aren't listed in the ini file. [11:56] Vincent.Sylvester @hg.zetaworlds.com:8002: The compiler errors are usually very descriptive unless you broke something internally [11:56] Vincent.Sylvester @hg.zetaworlds.com:8002: You ideally shouldn't need to adjust heap at all [11:56] Kayaker Magic: If people use old OpenSim.ini settings for YEngine heap sizes, that can cause the problem you describe [11:56] Andrew Hellershanks: The error is the generic one -> NullReferenceException: Object reference not set to an instance of an object [11:57] Vincent.Sylvester @hg.zetaworlds.com:8002: Also I think latest release should have proper heap size calc in there, was a bug on that before [11:57] Ubit Umarov: http://opensimulator.org/wiki/YEngine [11:57] Ubit Umarov: "Memory heap and stack use control" very clear there [11:57] Vincent.Sylvester @hg.zetaworlds.com:8002: Always test with release or master code [11:58] Vincent.Sylvester @hg.zetaworlds.com:8002: I'd be curious to see that script and figure out where it generates all that heap [11:58] Andrew Hellershanks: YEngine will accept ini settings to set the stack and heap sizes but those settings are not in the existing ini files. [11:58] Vincent.Sylvester @hg.zetaworlds.com:8002: Haven't had a single script hit those limits yet [11:58] Vincent.Sylvester @hg.zetaworlds.com:8002: Well outside of testing for it specifically [11:58] Andrew Hellershanks: I'm not as concerned about the heap issue as much as I am about the exception when trying to compile the code. [11:59] Vincent.Sylvester @hg.zetaworlds.com:8002: Yeah that you kinda need to have a debugger connected to it I guess [11:59] Andrew Hellershanks: I found the YEngine has some settings for debug modes but the debug ones that are supposed to save the original script and save the IL file don't seem to work (or the file was saved somewhere other than I expected). [12:00] Ubit Umarov: they are at opensimdefaults.ini [12:00] Vincent.Sylvester @hg.zetaworlds.com:8002: Mean like visual studio to see directly in code where it barfs [12:00] Andrew Hellershanks: Vincent, Yes, that is what I was planning on doing. I might add some extra debug code as the backtrace tells me where it dies. [12:01] Vincent.Sylvester @hg.zetaworlds.com:8002: If you get anywhere with it feel free to mantis it so others can test as well, more brains the better to figure illusive things like that out [12:01] Ubit Umarov: yeah to read the IL will help you a lot :p [12:01] Andrew Hellershanks: I didn't write the two scripts in question. One is almost 4600 lines line. [12:02] Andrew Hellershanks: Ubit, I know. I was just hoping to find something that might help narrow down what is triggering the exception. [12:02] Andrew Hellershanks: A debugger or adding in extra debug messages may be my best option. [12:02] Ubit Umarov: x had no control of mem usage [12:03] Vincent.Sylvester @hg.zetaworlds.com:8002: If they are that long maybe what you are seeing is the fail on the heap allocation itself [12:03] Ubit Umarov: so it is normal that some scripts will try to eat all memory [12:03] Andrew Hellershanks: It had a 256k stack size setting in the ini but that was about it. [12:03] Vincent.Sylvester @hg.zetaworlds.com:8002: You almost have as bad a luck with bugs as I do lol [12:03] Ubit Umarov: Y controls stack and heap [12:04] Andrew Hellershanks: Vincent, that's what I'm thinking. it would have been nicer if it had said that in the first place and not just no ref to object. [12:04] Andrew Hellershanks: Vincent, only when it isn't my code. [12:04] Ubit Umarov: and yes in same cases ppl need to make those very large to run old X scripts [12:04] Selby.Evans @grid.kitely.com:8002: byr all [12:04] Andrew Hellershanks: This is part of a compatibility test to see what changes (if any) need to be made to the script so it works in YEngine. [12:05] Ubit Umarov: well assuming it did fail by controled Yengined stach overflow [12:05] Kayaker Magic: Bye Selby! [12:05] Ubit Umarov: cya Selby.Evans [12:05] Andrew Hellershanks: Selby, ok. Thanks for being here. [12:05] Ubit Umarov: it may had crash because native stack overflow :) [12:05] Vincent.Sylvester @hg.zetaworlds.com:8002: Well my best guess is that with scripts that long there is probably something in there not up to proper LSL standard and it's barfing on that. I have seen a lot of old scripts written under X perform poorly because they used bad list appends and such things. Fixing those and writing in proper LSL standard you get performance and less issues with memory consumption [12:05] Ubit Umarov: well when ubode does that, it is very visible :) [12:06] Vincent.Sylvester @hg.zetaworlds.com:8002: Rewriting script that large not so easy of course, might be better to just lint it a bit [12:07] Andrew Hellershanks: Vincent, That is part of my question. Is it something bad in the script or something in the YEngine code. I wasn't expecting an exception during what I think is just the compilation phase. [12:08] Ubit Umarov: well it depends on what you call exception [12:08] Ubit Umarov: "exception" can be a lot of things [12:08] Vincent.Sylvester @hg.zetaworlds.com:8002: Line 2547 probably and maybe the list append on line 574, need to see the script to determine that really [12:08] Andrew Hellershanks: What I call an exception is that thing that is reported by YEngine as ...Exception in the error message. [12:09] Ubit Umarov: it usually tells more [12:10] Vincent.Sylvester @hg.zetaworlds.com:8002: Well null reference errors are something you see on parts of code that try to get properties or iterate for example. It tells you a reference is missing which means whatever code is trying to interact with an object the object has changed format for example. That's just one way that can happen though. Given it runs out of heap perhaps internal structures like list sizes are exceeded when it allocates space for them so the reference to each item falls apart [12:10] Andrew Hellershanks: Sure. There is a backtrace. [12:11] Ubit Umarov: it is on on compile that it has nothing to do with those script memory settings [12:11] Ubit Umarov: if it is.. [12:11] Kayaker Magic: Andrew: I just looked up YEngine stack and heap sizes, the recommended values are 2048 and 1024, This changed at one point, it sounds like you had the old smaller values. [12:11] Ubit Umarov: Grrr [12:11] Ubit Umarov: he now said it is on compile.. [12:12] Ubit Umarov: just need to read the damm message [12:12] Andrew Hellershanks: The first error I ran in to was the Exception that appeared when I told the viewer I wanted to compile the scripts. Once I received an updated version of the code I just got the HeapException error. [12:12] Vincent.Sylvester @hg.zetaworlds.com:8002: ... we be poking in the dark here without script and logs basically, if you cannot figure it out this week just mantis it :) [12:12] Ubit Umarov: sure, some are still criptic.. [12:13] Object: Script running [12:13] Andrew Hellershanks: Now that I have doubled the heap size I will try compiling the scripts once again on the original version of code in case the no ref to object exception is also heap related. [12:14] Ubit Umarov: no ref to object is a more severl thing [12:14] Ubit Umarov: just get the full error [12:15] Andrew Hellershanks: I would discuss it in the IRC channel but I still can't reach the channel since the nationwide Internet outage on Friday. [12:15] Ubit Umarov: oh? [12:16] Vincent.Sylvester @hg.zetaworlds.com:8002: Just mantis it if you get nowhere with it this week or something, better get more brains looking over it and I been cleaning up the mantis as best as I can so feel free to add lol [12:16] Andrew Hellershanks: yea. A major Internet and cell phone provider experience an outage on Friday starting around 5am. I didn't get Internet back until around 10:30pm. Some people were expected to be out as many as 3 days. [12:16] Vincent.Sylvester @hg.zetaworlds.com:8002: BGP again they say [12:16] Ubit Umarov: wel in this case, a mantis without the scropt to repo is a problem [12:16] Ubit Umarov: script.. [12:17] Ubit Umarov: and provide the script, specially a large one, can be a issue [12:17] Andrew Hellershanks: Vincent, sure. My notes say that even with the larger heap size it still throws an exception when I ask for the scripts to be compiled. [12:17] Vincent.Sylvester @hg.zetaworlds.com:8002: Script and logs, well steps to reproduce and logs in most cases [12:17] Ubit Umarov: ohh [12:17] Andrew Hellershanks: If I am allowed to provide the script I will mark it private. [12:18] Ubit Umarov: it may just be a missing script [12:18] Kayaker Magic: Finding a small script to reproduce an error is often difficult. [12:18] Ubit Umarov: that may give a null ref error [12:18] Andrew Hellershanks: To repro the problem just right click object, more, more, scripts, compile (Mono). [12:18] Ubit Umarov: yeap sounds like a missing script asset [12:18] Ubit Umarov: read the error message [12:19] Andrew Hellershanks: at OpenSim.Region.ScriptEngine.Yengine.XMRInstance.PostEvent (OpenSim.Region.ScriptEngine.Shared.EventParams evt) [0x0001f] in XMRInstRun.cs:69 [12:19] Andrew Hellershanks: at (wrapper remoting-invoke-with-check) OpenSim.Region.ScriptEngine.Yengine.XMRInstance.PostEvent(OpenSim.Region.ScriptEngine.Shared.EventParams) [12:19] Andrew Hellershanks: etc... [12:19] Vincent.Sylvester @hg.zetaworlds.com:8002: Most obvious problem with that used to be too small packet size on the database to store the asset [12:19] Andrew Hellershanks: I'll see if I can learn anything more about it and mantis. [12:20] Ubit Umarov: on a post event? [12:20] Ubit Umarov: odd [12:20] Andrew Hellershanks: hm... now that is an intereting thought, Vincent. [12:20] Ubit Umarov: well can't guess [12:20] Ubit Umarov: and that is running it [12:20] Andrew Hellershanks: The text of the script as sitting on my computer is 211772 bytes long. [12:21] Ubit Umarov: or starting [12:21] Vincent.Sylvester @hg.zetaworlds.com:8002: Used to have like 16mb of max packet size on older mysql versions, since then it was increased default value should be much higher now like 1G even on some flavors [12:22] Ubit Umarov: well scripts used to have a limit of 64k bytes on sources [12:22] Vincent.Sylvester @hg.zetaworlds.com:8002: Was big fail on HG assets back then [12:22] Andrew Hellershanks: Ubit, It does look a bit more like it is an issue after the script starts to run. Something to do with llMessageLinked. I am thinking of adding extra code in to LSL_Api.cs to print out what the function receives. [12:23] Ubit Umarov: but that seems is needs a more detailed debug [12:23] Andrew Hellershanks: The Engine is dying and not leaving any useful information about what line of the script it was trying to run at the time it die.d [12:23] Ubit Umarov: that is not on lsl_api [12:23] Andrew Hellershanks: I was hoping one of the Debug settings would help. [12:23] Andrew Hellershanks: llMessageLinked is not in LSL_Api.cs?? [12:23] Ubit Umarov: and it is that one ? [12:24] Andrew Hellershanks: That function is mentioned further down in the backtrace. [12:24] Ubit Umarov: well i can't guess what you didn't told :p [12:24] Vincent.Sylvester @hg.zetaworlds.com:8002: It's like a fox hunt with an invisible fox [12:25] Ubit Umarov: nahh just very bad problem report [12:25] Ubit Umarov: :p [12:26] Vincent.Sylvester @hg.zetaworlds.com:8002: If you don't get anywhere debugging it mantis it, if they don't want to share set it to private so at least Ubit can have a look at it [12:26] Andrew Hellershanks: Yes, the script would have to be marked private. [12:27] Vincent.Sylvester @hg.zetaworlds.com:8002: Dirty secrets lol [12:27] Andrew Hellershanks: Proprietary code that is part of a larger system. [12:28] Vincent.Sylvester @hg.zetaworlds.com:8002: Hopefully not some multi pose animation thing, haven't seen a single one written properly yet they are all massively over complicated and poorly written to the point they consume a ton of resources [12:28] Vincent.Sylvester @hg.zetaworlds.com:8002: Some just don't even work anymore under Y [12:29] Vincent.Sylvester @hg.zetaworlds.com:8002: Or use ossl functions that need to be set true [12:29] Andrew Hellershanks: Vincent, interesting that they some don't work in Y (assuming it isn't just perms). [12:29] Vincent.Sylvester @hg.zetaworlds.com:8002: They fail on the lists they generate or on typecasts [12:29] Andrew Hellershanks: Probably not too surprising though. [12:30] Andrew Hellershanks: oh, right. Probably ones that use the "memory saving trick". [12:30] Vincent.Sylvester @hg.zetaworlds.com:8002: Also prime suspects for that "scripts stopped working" thing I mentioned earlier [12:30] Vincent.Sylvester @hg.zetaworlds.com:8002: Oh yeah when that happens the things like llSetText also don't update so there is a hint at which queue that is [12:31] Vincent.Sylvester @hg.zetaworlds.com:8002: But yeah if you don't get anywhere just make a private mantis ticket for it [12:32] Ubit Umarov: yeha guess that will take some deeper debug [12:33] Misterblue Waves: gotta run... take care all [12:33] Ubit Umarov: cya [12:34] Andrew Hellershanks: As long as I can still access the mantis. Don't know why I still can't access the IRC channels. [12:34] Ubit Umarov: but that means there are more scripts [12:34] Andrew Hellershanks: ok, Misterblue. [12:34] Andrew Hellershanks: We are now half past the hour. Unless there is any last minute items I will wrap up the meeting. [12:34] Ubit Umarov: on the linkset [12:35] Ubit Umarov: so guess the entire object will be needed to debug [12:37] Andrew Hellershanks: ok, I'll call this one done and dusted. :) Thank you all for coming. See you again next week.