Réunion du 03-12-2024

De OSWiki
Aller à la navigation Aller à la recherche

Changements du code de la semaine

Correction de bogues sur la nouvelle fonction llRezObjectWithParams

Croisement de région avec UbODE

  • Commit 4b993d : modifier le point de chute des avatars lorsqu'ils sortent des limites de la région dans UbODE.
  • Lorsqu'un avatar sort du cadre, ubode le place près du bord. Le code vérifie si le prochain mouvement à la vitesse courante l'enverra dans une autre région.
  • Dans une direction, sans savoir pourquoi, l'avatar était placé trop loin du bord, ce qui l'empêchait de traverser la frontière en marchant.

Avertissement

Attention : Ce résumé existe pour orienter vos recherches. Des erreurs d'interprétation ne sont pas à exclure. Pour plus de précisions, veuillez vous référer aux sources ou vous adresser directement aux développeurs d'OpenSimulator en assistant aux réunions du mardi ou sur le canal IRC. Je ne fais pas partie des développeurs, ne vous adressez pas à moi pour les joindre. Merci.😉


Scripts

Distance de rezz

  • 🏗️

Modules

Moteur physique : UbODE

Le problème

  • Vincent Sylvester et Ubit Umarov se sont amusés à sauter dans des murs de briques la tête la première pendant un moment pour essayer de déboguer un crash physique.
  • Ce crash semble causé par la configuration de la compilation . Depuis Dotnet la compilation en mode débogage semble faire apparaître des problèmes alors que la configuration en mode release semble correcte et ne provoque pas de crash.
  • Le crash se produit alors que le système semble boucler à l'infini en interne et plante lors de l'allocation de la mémoire.

Mode débogage et mode release

NDLR  :
  • La compilation de code est le processus de transformation du code source écrit par un développeur en un programme exécutable par un ordinateur.
  • En mode débogage, le code est préparé pour faciliter le test et la correction des erreurs.
  • En mode release, le code est optimisé pour être plus rapide et prêt à être distribué aux utilisateurs.

Le mode débogage inclut des informations utiles pour le développement, alors que le mode release se concentre sur la performance.


Analyse du problème

  • Ubit Umarov pense qu'Opensim devrait être compilé et exécuté en mode Release, même sur mono 6.x. Le mode débogage est très lent maintenant et le code est même très différent dans certains cas.
  • Vincent Sylvester dit qu'il n'y a pas de backtrace[1], juste une terminaison du simulateur avec what() bad_alloc. Le problème se situe quelque part dans le code de bas niveau d'UbODE qui recevrait de mauvaises données du simulateur en provoquant un crash. C'est très loin, donc sans plus d'informations, il est presque impossible à déboguer, à moins de vouloir parcourir tout le code d'UbODE ligne par ligne. Maintenant il utilise les deux types de compilation (debug et release) et n'utilise le mode debug que lorsqu'il y a un problème.
NDLR  :

bad_alloc : le programme a tenté d'allouer de la mémoire, mais cette allocation a échoué.


  • Garbage Collector" (GC)[2] en mode debug n'est pas le même qu'en mode release.

La pile

NDLR  :
  • Dans les environnements de programmation, la pile [3]est une zone de mémoire utilisée pour stocker des informations temporaires, comme les variables locales et les adresses de retour des fonctions.


  • Ubit Umarov demande si Vincent Sylvester a déjà augmenter la taille de la pile pour UbODE. Il indique que dotnet utilise aussi beaucoup de pile, ce qui pourrait aggraver le problème de débordement de pile.
  • Sous Linux, on peut augmenter la taille de la pile dans le script opensim.sh placé dans le dossier bin d'OpenSim. On peut aussi le faire dans la configuration de la machine quelque part dans le dossier /etc.

Informations

OSCC 2024

NDLR  :


Maintenance d'Osgrid

  • Situation de la grille la semaine dernière.
  • La grille est à nouveau hors ligne. Les services d'assets d'OSGrid sont toujours hors service et la grille a dû arrêter l'utilisation des assets par le public, la migration n'a pas aimé se dérouler en parallèle. Il semblerait qu'il y ait eu un problème avec la taille du cluster.
  • OSgrid utilise Ceph[4] pour stocker ses données. Tous les assets sont dans un système de fichiers.
  • En ce moment personne ne peut se connecter à Osgrid à part les utilisateurs qui ont le mode dieu (god). Les développeurs d'opensim ont le mode dieu sur Osgrid par tradition. Cela devrait apparaître sur le profil.
NDLR  :
  • Extraits de l'article posté sur le site d'Osgrid [5] traduits avec DeepL[6].
Retour à la maintenance
par Osgrid|Publié le 30 novembre 2024

Malheureusement, la nuit dernière, la restauration incrémentale a échoué, poussant le cluster dans un état inutilisable. Il a commencé à refuser activement toute nouvelle connexion et pour éviter des dommages, la grille a été à nouveau mise hors ligne et mise en mode maintenance. [...].

Questions et réponses :

Pourquoi ne pouvez-vous pas nous dire immédiatement ce qui a échoué ?
=====================================================================
Parce que nous sommes des techniciens et non des médiums informatiques. Nous observons un problème, essayons d'en trouver la cause et voyons si nous pouvons le résoudre. Mais tout n'est pas simple et évident, et même si les pannes sont évidentes, il faut parfois du temps pour en trouver l'origine. Le réseau s'éteint et nous envoyons un message d'alerte. Nous savons que le cluster est très sollicité. Il est arrivé que des problèmes soient dus à cette charge de travail, alors que l'écriture d'un processus s'interrompait. Mais la raison d'une défaillance n'est pas toujours évidente. Il peut s'agir d'un manque de ressources, d'une fuite de mémoire, d'une attaque contre nos serveurs, d'une panne de réseau, d'un code cassé, d'un problème de système ou de configuration, ou d'un tas d'autres choses. Mais ce sont des actifs que nous traitons. La priorité numéro 1 est donc de protéger vos « biens ». Nous ne mettons pas le réseau hors service si nous n'en ressentons pas le besoin.

Combien de temps cela prendra-t-il ? 
====================================
Nous ne pouvons pas répondre à cette question. L'hypothèse la plus plausible est que nous avons probablement rouvert le site trop tôt. [...] Il ne s'agit pas d'un nouveau problème. Nous ne pouvons que vous demander de tenir bon.
[...]


Réunion

  • La réunion de ce jour s'est déroulée sur http://hg.zetaworlds.com/OpenSim
  • La réunion de la semaine prochaine c'est à dire du 10 décembre 2024 aura lieu au même endroit si Osgrid est encore hors-ligne.

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-12-03

Récupérée de « https://cogito.no-ip.info/cogito/OSWiki/index.php?title=Réunion_du_03-12-2024&oldid=11418 »