Tu pointes ?

En Fortran, utiliser la fonction associated sur un pointeur non défini est définitivement une mauvaise idée. Cette fonction retourne vrai si le pointeur a une cible, faux s'il est nul mais la fonction est théoriquement indéfinie (vrai ou faux) si le pointeur est lui-même indéfini ; ce qu'il est, par exemple, juste après sa déclaration.
J'en ai fait l'expérience aujourd'hui.

En décor, vous avez un code de 100 000 lignes développé, à 350 km de là, par 4 personnes, pour leur propre recherche et celle de quelques rares collaborateurs.
Une petite équipe donc. D'autant que chacun ne connaît pas forcément en détails la contribution des autres. Ce qui peut conduire à des situations critiques.
Il y a ces 20 000 lignes de code produites par quelqu'un qui vient de quitter la recherche. Et lorsque vous demandez aux autres, à propos de cette partie, « comment ça marche ? » Ou si vous vous retroussez les manches et que vous plongez dans le code et que vous demandez pourquoi telle méthode est utilisée dans ce cas et telle autre dans cet autre cas ?
La réponse est : je ne sais pas.
C'est un code très peu documenté.
Il donne de très beaux résultats, mais travailler dessus n'est pas une mince affaire.
Il se trouve que depuis 15 jours je fais partie des quelques rares privilégiés qui ont accès à ce code.
Ca devait se faire depuis mars 2006...
Mais la peur non avouée d'un espion français dans une collaboration d'essence autrichienne a ralenti considérablement l'affaire.
Alors en juin dernier j'ai envoyé la balle dans leur camp en leur développant gracieusement un petit paquetage exprès pour ce code pour traiter équation d'état et opacités. Du fait, ils étaient un peu au pied du mur.
Ca arrive un peu tard pour mes projets. Trop tard peut-être.
Mais mieux vaut tard que jamais, non ?

Je reviens à mes moutons.
J'ai donc une version de ce code qui fonctionne et dont je me sers pour mes simulations.
Hier je décide de faire un petit changement, vraiment minime.
Je teste. Pas de problèmes.
Je compile, avec les optimisations usuelles. 1h30 de compilation.
Je mets dans la queue de production en fin de journée.
Ca se lance.
Ca se crashe lamentablement.
Où ? Difficile à dire. Mais manifestement pas à l'endroit où j'ai fait des modifications.
De plus je ne reproduis pas le dramatique segmentation fault avec ma version de test.
Seule la version parallèle de production se meure.
Après une nouvelle compilation avec des exigences d'optimisation moindres, ça fonctionne de nouveau.
Je laisse tourner comme ça, mais ça n'est pas satisfaisant.
Je veux savoir ce qui fait planter.
Alors aujourd'hui à force de « je suis le CPU #n et je rentre dans la routine Bidule » et autre « moi CPU #n je viens d'affecter/d'allouer machin » et de patientes recompilations optimisées, j'ai fini par localiser l'endroit du plantage puis d'en trouver la cause.
Cause décrite en préambule.
Celui qui avait développé la routine testait si un tableau déclaré comme pointeur était déjà associé à une cible avant de lui allouer de la mémoire. Or si le test de ce pointeur non défini donnait jusqu'à présent toujours faux comme résultat, suite à la modification que j'ai faite dans deux autres routines totalement différentes, le résultat de ce test est devenu vrai.
Ce soir j'ai relancé la suite de la production, avec un programme correctement optimisé et une option de compilation supplémentaire nullifiant les pointeurs à leur déclaration.
Ca roule.
Je suis content.
Je vais dormir.