« Investir au PanamaPotasse à tout va »

Solaris

19.12.10 | par Le Grincheux | Catégories: Mauvaise humeur, Je hais l'informatique, Vieux con

Je me demande de plus en plus souvent comment j'ai réussi à apprécier les processeurs SPARC en haïssant au plus au point Solaris. En étant tout à fait honnête, je pense que le meilleur de la série était Solaris 2.5.1, à moins qu'il ne s'agisse de Solaris 5.1 ou de SunOS 5.1, je n'arriverai jamais à comprendre pourquoi il existe tant de numérotations différentes pour le même produit. Pourtant, le passage de SunOS 4.1 à Solaris 2.5 a été rude puisqu'on est passé de quelque chose qui ressemblait à un BSD à quelque chose qui approchait un SysV. Aujourd'hui, Solaris 10 ne ressemble plus à rien donc la question ne se pose pas.

Solaris 2.5.1 était stable, solide et, ce qui ne gâche rien, administrable par un être humain normalement constitué, c'est-à-dire avec deux mains, deux yeux et un cerveau non hypertrophié. Le 2.6 a amorcé la chute puisqu'il accusait déjà quelques instabilités amusantes, instabilités confirmées par le 5.7. Quant à Solaris 8, il est capable de paniquer sur un changement d'adresse IP d'une carte réseau, ce qui fait tout de même désordre. Je ne sais pas si vous arrivez à suivre la numérotation de la chose, Solaris 8 est le successeur du 5.7, lui-même successeur du 5.6 qui a immédiatement suivi le 2.5.1… Solaris 9 est parfaitement instable sur architecture sun4m dès qu'une machine embarque plus de deux processeurs HyperSPARC. Avec deux SuperSPARC-II, ça semble passer, mais c'est tout de même, vous en conviendrez facilement, un peu bizarre.

Depuis plus d'une dizaine de jours, je cherchais un problème dans un programme de plusieurs centaines de milliers de lignes de code méchamment multithreadé. Le problème ne se produisait que sous Solaris 10 sur architecture sun4v. Après avoir installé une machine de test sun4u avec la même version de Solaris aux patches près, je n'ai pu reproduire le problème. Étrange me direz-vous.

Les différentes techniques de debogage sous Solaris n'ont rien donné :

  • libumem échouait lamentablement sur une erreur de bus dès que les variables d'environnement imposaient un fonctionnement en mode débogage ;
  • watchmalloc plantait immédiatement sur une erreur de segmentation ;
  • mdb n'aime pas du tout le code multithreadé et perdait les pédales ;
  • dbx devrait s'appeler « daube-X » car il est capable de planter au chargement de l'image avant même d'avoir commencé son exécution ;
  • purify ne renvoyait aucune erreur. Plus exactement, purify râlait sur des problèmes internes à la libc de Solaris, jamais sur mon propre code.

Après avoir isolé un certain nombre de paramètres, je me suis rendu compte que le problème de corruption du tas ne se produisait qu'après l'initialisation d'un connecteur PostgreSQL et que cette corruption était indépendante de la version de PostgreSQL utilisée. En utilisant des options strictes de la libumem, j'obtenais une erreur de segmentation reproductible dans la fonction getaddrinfo() appelée par la bibliothèque PostgreSQL. Plus exactement, dans une fonction censée allouer de la mémoire pour une structure de description d'une addresse IPv6.

La machine en question n'utilisait pas la pile IPv6. Curieux, j'ai configuré une interface en IPv6 et, miracle, mon programme s'est mis à fonctionner. En remplaçant la fonction livrée par Solaris par une fonction codée par mes soins, cela fonctionne même sans aucune interface configurée en IPv6.

Élève le Grincheux, vous me copierez donc cent fois :

« je ne dois jamais utiliser la fonction getaddrinfo() de Solaris 10 sur architecture sun4v lorsque la pile IPv6 est désactivée. »

Et dire qu'Oracle vend maintenant ce produit. Au moins, Sun avait la décence de ne plus le faire payer !

 

Aucun commentaire pour le moment


Formulaire en cours de chargement...