Discussion :

[rambc]

Bonsoir,
mon problème est simple à exposer mais peut-être plus dur à résoudre...

J'ai un gros projet qui compilé en 64 bits renvoie une "segmentation fault", faute qui n'est pas renvoyé si on compile en 32 bits. La bonne solution serait de partir à la chasse de cette erreur mais voilà le code n'est pas de moi et il est monstrueux (dans tous les sens du terme)...

J'arrive à ma question. Peut-on simuler une compilation 32 bits sur un OS 64 bits ? Je suis Linux Ubuntu et j'utilise CodeBlock.

[Obsidian]

Bonsoir,

J'arrive à ma question. Peut-on simuler une compilation 32 bits sur un OS 64 bits ? Je suis Linux Ubuntu et j'utilise CodeBlock.

Oui, et à dire vrai, ton O.S. est déjà prévu pour le faire. Les distributions de Linux fonctionnant sur architecture x86_64 sont pour ainsi dire toutes faites pour embarquer les versions 32 et 64 bits de leur packages.

Par contre, il est probable que cela ne règle pas le problème : si tu obtiens une segfault en 64 bits et pas en 32, c'est que le programme est nativement bugué, qu'il peut planter à la moindre modification de son environnement original et, pour être franc, même si tu reconstitues entièrement cet environnement puisque c'est une erreur aléatoire.

Il m'était arrivé la même chose il y a six, huit ans en portant un programme C depuis un serveur Sun Solaris vers une machine Linux. Le logiciel générait des pages web en CGI et était appelé depuis un serveur Apache. Segfault systématique après recompilation et mise en place. Je m'étais rendu compte que non seulement il était congénitalement bugué mais qu'en réalité, il plantait sur la machine source, à chaque fois et depuis le départ ! Par contre, il plantait après la génération de la page et non avant comme sur la machine cible, si bien qu'on ne s'en était jamais rendu compte jusque là. C'était une application développée par un bio-informaticien qui avait quitté le centre à la date où je me suis penché dessus.

Autrement dit : ton programme a beau être monstrueux, c'est en mettant quand même les mains dans le cambouis et en isolant l'erreur que tu perdras le moins de temps à terme.

[Sve@r]

...Je m'étais rendu compte que non seulement il était congénitalement bugué mais qu'en réalité, il plantait sur la machine source, à chaque fois et depuis le départ ! Par contre, il plantait après la génération de la page et non avant comme sur la machine cible, si bien qu'on ne s'en était jamais rendu compte jusque là....

Salut
Excellente histoire.

[Bktero]

C'était une application développée par un bio-informaticien qui avait quitté le centre à la date où je me suis penché dessus.

Avec des détails croustillants !

[rambc]

Même si cette histoire est horrible , c'est bien ce que je craignais...

[Obsidian]

Salut
Excellente histoire.

Avec des détails croustillants !

On en voit de belles dans une carrière professionnelle. :-) Il y avait également cet exemple-ci.

Je pourrais aussi parler du gars qui nous avait fait une page interactive en interne également, avec différents boutons, formulaires et autres gadgets interactifs, mais qui ne fonctionnait que sous Internet Explorer. Sous Firefox qu'on utilisait à peu près partout, la page s'affichait correctement, mais était totalement immuable. Tous les clics et autres événements utilisateurs étaient complètement ignorés.

Technologie Microsoft, contrôles ActiveX, scripts VBScript faisant appel à des bibliothèques Windows propriétaires ? Non. Bug de Firefox alors ? Non. Erreur d'interprétation des C.S.S. (qui ont longtemps été une calamité) ? Presque… mais pas de la part du navigateur en cause !

En fait, notre développeur avait écrit sa page en tâtonnant tant qu'il pouvait, et avait superposé les layers invisibles, qui recouvraient de deux ou trois couches parfois les formulaires de la page en question. Internet Explorer, lui, ne faisait qu'un rendu approximatif des C.S.S. et considérait le travail terminé. Les boutons, eux, et une fois déclarés, faisaient partie de la GUI du système et interceptaient les événements avant même qu'ils n'atteignent le document. Firefox, lui, faisait les choses proprement en transmettant les événements aux éléments d'avant plan.

Suppression des éléments superflus et inutiles dans le code source de la page et l'application est redevenue utilisable partout. Je n'ai pas souhaité passer plus de temps à la nettoyer non plus. :-)

Il y a eu des choses nettement plus graves mais que je les tairai car elles ont beaucoup pourri nos conditions de travail à l'époque.

Même si cette histoire est horrible , c'est bien ce que je craignais...

Ne crains rien. Fais tourner ton application dans un débogueur et utilise des outils comme valgrind qui t'aideront déjà beaucoup. N'oublie pas non plus de faire une compilation la plus stricte possible avec les bonnes options. La majorité des problèmes seront résolus en amont.

[matafan]

Elles sont belles vos histoires, mais il est également possible que l'appli ait été (mal) développée en 32 bits, et que l'erreur en 64 bits vienne, par exemple, de casts de pointeurs en int (volontaires ou involontaires... Voire par exemple le fameux cast du malloc quand on n'inclue pas stdlib.h). Dans ce cas elle peut très bien planter systématiquement en 64 bits, et fonctionner parfaitement en 32 bits.

Sinon oui, ton OS 64 bits est capable de faire tourner des applis 32 bits. Mais il faut aussi avoir une version 32 bits de toutes les libs dont dépend l'appli.

[rambc]

Une voie à explorer... Merci !