Comment détecter une incompatibilité binaire avant de lier dynamiquement une bibliothèque ?

Bonjour

Je viens de passer un peu (trop) de temps à investiguer un bug qui causait une segmentation fault.

Sur un projet un peu volumineux où le code est construit par module sous la forme de bibliothèques liées dynamiquement, j'ai une lib qui expose une classe Foo, avec un constructeur sous la forme :

Foo::Foo(std::shared_ptr<Bar> bar){
// ...
}

Bar étant une classe abstraite. C'est l'exécutable qui possède une classe dérivée de Bar et fournit l'implémentation.
La segfault se produit lorsque l'on tente d'accéder à un champ de Bar.
bar->champBar; // crash

Je n'avais pas de crash si je tentais d'accéder à une fonction virtuelle. Pas de crash non plus si le constructeur était inliné dans le header Foo.h.
Dans un premier temps, j'ai cru à un problème de slice, et j'ai cherché à débusquer un appel implicite à un constructeur de copie, en vain.

Finalement, il s'est avéré que lors du build de la lib et de l'exécutable, une des dépendances de Bar n'était pas configurée de la même façon, causant une incompatibilité binaire entre l'interface et l'implémentation.

Existe-t-il un moyen de mettre en évidence ce type de problème lors de l'édition des liens (j'utilise gcc et la configuration de build est gérée sous CMake) ? Ou au moins un outil d'analyse des binaires qui pourrait relever le problème avant que l'appli ne crashe lamentablement à l'exécution ?

Vous avez eu de la chance jusqu'à présent, et vous avez encore de la chance en ayant des segfault au moment de l'accès et pas des erreurs ailleurs, bien après et dans du code qui n'a rien à voir.
(Utilisation d'options de build avec utilisation massive de canaries en Debug ?)
Votre application était tombée en marche jusque-là.

Il n'y a pas d'ABI (standardisation du binaire) en C++, contrairement au C.

Il est donc complètement illusoire et dangereux d'utiliser des classes/fonctions manglées C++ dans les API entre modules binaires (EXE et DLL) ; mais avec les librairies statiques, il faut généralement faire la génération des .lib avec les mêmes options que son client : utilisation des concepts de projets de votre IDE préféré.

Pour les problèmes de compatibilité "structurelle" comme la version de la C-RUNTIME, le code dans les headers vérifie la présence et la valeur de certaines constantes de compilation pour détecter l'utilisation de C-RUNTIME différentes/incompatibles avec les options "locale" du fichier à la compilation.
Les informations qui passent entre le compilateur de M$ (cl.exe) et l'éditeur de lien de M$ (link.exe) permettent aussi de détecter ces mélanges au moment de l'édition de lien. (via les .lib généré mais aussi bien d'autres fichiers (.pdb, etc...))

Mais si vous avez une structuration en couche cohérente avec les dépendances, et que vous compilez bien TOUS (.lib, .dll, .exe, .ocx, etc...) (tout ce qui est lié à ce qui a changé, donc la définition de l'interface abstraite est en source de dépendance de la lib et le client de la lib et dépendante de la lib : compilation de la couche de l'interface abstraite + compilation de la lib + compilation du client de la lib ) avec le même compilateur ET les mêmes options, vous ne devriez pas avoir ce type de problème. (Mais on perd beaucoup de l'intérêt du découplage en couche)

Mais une API "objet" pour une Dll, c'est caca.

Salut,

Citation:

---

Envoyé par Grool

le code est construit par module sous la forme de bibliothèques liées dynamiquement, j'ai une lib qui expose une classe Foo, avec un constructeur
... une classe abstraite ... l'exécutable ... fournit l'implémentation.

---

Dans quel intérêt tu fais ça ?
Si je ne m'abuse, en programmation modulaire on s'arrange pour avoir un couplage faible, dans ton cas, il me semble carrément circulaire.
Sauf les tests unitaires, je ne vois pas comment tu peux débusquer tes problèmes d'incompatibilités.
Et sinon, à part le PImpl, regarde du côté de la communication interprocessus. Il y a par exemple la programmation orientée composant qui n'est pas loin de ce que vous faites, mais qui offre déjà plus de stabilité.

Bonjour

Merci pour les réponses.

Alors, pour donner un peu plus de détails.
C'est justement les tests qui se vautraient en segfault. Et c'est en particulier un bouchonnage qui modifie une dépendance.

Cependant, ce problème peut être plus général et arriver sur l'appli si jamais une erreur se glisse dans les scripts CMake.

Je ne connais pas l'historique des choix d'archi, mais je ne vois pas trop l'intérêt des liens dynamiques. Je vais tenter de tout repasser en statique.

Comme l'indique @kaitlyn, il semble avoir des dépendances circulaire, ce qu'il ne devrait jamais arriver.
Mais qui arrive si on ne fait pas une architecture en couche + conception soignée des dépendances entre les modules de chaque couche.
On n'a l'impression que l'exécutable, donc la couche la plus haut, défini un truc qui est utilisé par une lib, qui naturellement est une couche plus basse que l'exe.
C'est le genre de cochonnerie qui passe "inaperçu" (quand on ne fait pas de refactoring "sérieux") quand on ne fait que des librairies statiques.
Car tout est lié en un coup à la fin.
Donc votre approche de tout mettre en statique, c'est un peu la tactique de la tête de l'autruche dans le sable, c'est pas très pérenne.

Que vous ayez réussi à faire ce genre de truc avec des Dll, c'est bien plus complexe.
Mais j'ai l'impression que le passage de tout statique à un peu de dynamique est récent et que le "problème" que vous venez de vous prendre, c'est juste les conséquences de problèmes bien plus en amont.
Là, vous essayez de casser le thermomètre pour soigner votre fièvre.

Citation:

---

Je ne connais pas l'historique des choix d'archi, mais je ne vois pas trop l'intérêt des liens dynamiques.

---

Par exemple, détecter les architectures foireuses. :aie:

La classe abstraite doit être définie et implémentée dans une librairie, qui sera utilisé par l'exécutable et la librairie dynamique, donc plus de cycle à la con.
Comme il n'y aura pas de cycle, les outils de génération de projet type CMake devraient faire du bien meilleur boulot.

Après, c'est peut-être que vous vous êtes mal exprimé et que la conception n'a pas vraiment de dépendance cyclique (parce que c'est vraiment un piège pour très très débutant).

Citation:

---

...mais je ne vois pas trop l'intérêt des liens dynamiques.

---

Plus sérieusement, ç'est très variable en fonction de l'OS et du projet, mais, en général :
-lancement de l'application plus rapide
-plus de flexibilité sur des configurations machines et OS hétérogènes
-correction "automatique" de bugs ou de faille de sécurité
-économie d'espace disque
-gestion des versions plus simple (quand c'est bien fait, sinon, c'est un enfer encore plus sombre)
-etc...
(et sous Windows, vous n'avez pas le choix, les API de l'OS sont dans des Dll)

Citation:

---

un bouchonnage qui modifie une dépendance.

---

Ca sent pas l'architecture bien carrée à base de TDD tout ça.

Citation:

---

Existe-t-il un moyen de mettre en évidence ce type de problème lors de l'édition des liens

---

Si vous n'utilisez que des Dll et que vous faites une compilation depuis rien (pour éviter d'utiliser des .lib qui traînent), le linker devrait gueuler lors de l'utilisation d'un cycle de dépendance, car la génération d'une Dll interdit l'utilisation de choses non implémentées)

Mais, comme je l'ai déjà écrit, mettre des classes dans les API des Dll, c'est chercher les emmerdes.

Ouaip, quand on regarde les APIs C++ côté Microsoft, c'est soit:

• La libc etc., intrinsèquement dépendante du compilateur (et encore, plus récemment ils se sont débrouillés pour avoir un truc un peu plus souple)
• Microsoft Foundation Classes, dans le même cas
• Component Object Model, qui utilise une ABI standardisée (et utilisable depuis le C) justement pour éviter ce genre de problèmes.
• ou des APIs C++ entièrement exposées via des templates ou des classes inline, qui appellent la DLL via l'ABI C (comme GDI+)

Je suis sous Linux.

Je peux maîtriser le code de l'exécutable et des libs. Ce découpage n'est donc qu'un choix d'architecture. Une appli monolithique aurait pu être un autre choix, avec le risque d'en faire un plat de spaghettis.

Citation:

---

Donc votre approche de tout mettre en statique, c'est un peu la tactique de la tête de l'autruche dans le sable, c'est pas très pérenne.

---

Argh, mon but était plutôt de faire gueuler l'éditeur de liens.

Citation:

---

Mais j'ai l'impression que le passage de tout statique à un peu de dynamique est récent et que le "problème" que vous venez de vous prendre, c'est juste les conséquences de problèmes bien plus en amont.

---

Ce qui est récent, c'est l'accès direct à un champ. Auparavant, il y avait un accesseur virtuel. Et là pas de problème, on travaille avec une fonction de l'instance réelle qui connait le mappage de ses champs.

Citation:

---

Ca sent pas l'architecture bien carrée à base de TDD tout ça.

---

Non, non, en effet :roll:

Globalement, l'archi est :
un exécutable utilise un module sous la forme d'une lib .so.
Ce module dialogue lui-même avec d'autres modules. La classe abstraite regroupe tous les comportements communs de ces communications. C'est une sorte de client.

Alors maintenant, la question est pourquoi est-ce l'exécutable qui fournit les implémentations ? Il ne devrait même pas avoir connaissance du découpage des modules et de leurs interactions.
Si j'ai bien compris l'intention du gars qui a mis ça en place, il y a trouvé un moyen commode de substituer les clients par des stubs dans l'exécutable de test.
Ce qu'il a oublié, c'est que la classe abstraite repose sur des éléments de plus bas niveau (des signaux sigc) eux-mêmes bouchonnés lors du build de l'exécutable de test. La lib est par contre construite de la même façon dans toutes les configurations.

Le but de mon fil de discussion n'est pas tellement de trouver la faille de conception, mais bien de trouver un moyen de lever un warning comme la situation se présente. Car, à mon grand désarroi les cours de C++ passent trop de temps à présenter des syntaxes qu'on utilisera jamais plutôt que de parler des règles fondamentales d'architecture.

Il me vient un exemple que j'aurais pu naïvement programmer et qui m'aurait provoqué le même type de souci :
Un exécutable utilise une lib de code réutilisable en lui fournissant un objet dont la fonction est de gérer des callbacks. Chaque exécutable qui utilise la lib fournit sa propre implémentation. La lib appelle les callbacks selon les règles fixées par l'interface mais leur comportement est spécifique à chaque exécutable.
Avec une lib qui a une interface en C, il faudrait que l'exécutable envoie des pointeurs de fonctions libres ou statiques pour chaque callback, sans pouvoir tout regrouper dans une interface unique et claire.

Cela dit, je suis d'accord, une lib dynamique qui expose des classes en C++ est un nid à emmerdes. Déjà, parce qu'il n'y pas de norme pour le nommage des fonctions membres et les surcharges.
Par le passé, j'avais essayé d'utiliser la dll d'OracleDB avec MinGW, mais compatible seulement avec Visual C++.

Citation:

---

Envoyé par Grool

Avec une lib qui a une interface en C, il faudrait que l'exécutable envoie des pointeurs de fonctions libres ou statiques pour chaque callback, sans pouvoir tout regrouper dans une interface unique et claire.

---

As-tu regardé à quoi ressemblait COM (Component Object Model) ? Ça marche via des fonctions virtuelles forçant la convention d'appel C*: Vu d'un programme appelant en C++, c'est visible comme une bête interface (une classe avec juste des fonctions virtuelles)*; vu d'un programme appelant en C, c'est un pointeur vers un pointeur vers une structure contenant des pointeurs de fonction.

Pas encore, mais je te remercie du tuyau.

Salut,

COM fait partie des technos de la programmation orientée composant que j'ai précédemment évoquée. Personnellement, je le trouve un peu lourd et j'aurais tendance à privilégier quelque chose d’équivalent à XPCOM. Mais ce n’est pas un truc à prendre à la légère. Le concept est large, il faut bien creuser la question et choisir l'approche la plus adaptée, parce qu’une fois lancée, c'est très difficile de revenir en arrière.

Quoiqu'il en soit, avec un problème de conception quelque part, la mise en œuvre du projet n'en sera que plus difficile, donc il urge de travailler ce point. C'est seulement après que se posera la question du comment.

@Médinoc a fait un bon résumé des solutions "classiques" sous Windows, mais il y a peut-être des solutions plus adapté sous l'OS au pingouin.

J'ai une "affection" très particulière à la solution

Citation:

---

"des APIs C++ entièrement exposées via des templates ou des classes inline, qui appellent la DLL via l'ABI C (comme GDI+)"

---

parce que c'est assez portable et pas trop fonction du compilateur (s'il ne sent pas trop le patchouli des années 70).
Et j'ai l'impression que cela ressemble à une séquence "Transformers" où un dé de métal se transforme en un auto-bot de 100taine de tonnes. :mouarf:

Citation:

---

Ce qui est récent, c'est l'accès direct à un champ. Auparavant, il y avait un accesseur virtuel. Et là pas de problème, on travaille avec une fonction de l'instance réelle qui connait le mappage de ses champs.

---

Le traitement des fonctions virtuelles (via une v_table) est quelque-chose d'assez standardisé au cours des différentes versions d'un compilateur ou de famille de compilateur (mais certaines différences d'options, même sur le même compilateur peut rendre ces appels incompatibles).

Dans le cadre où vous maîtrisez la génération de TOUS les composants qui interagissent de cette façon, cela (l'utilisation d'une API 100% virtuelles) peut être une solution d'un certain type de Design Pattern.
Une approche à base de DTOs en est une autre, mais beaucoup moins polyvalente (basée sur le pilotage "fin" de la représentation des structures partagées et donc des options de compilation y afférant).

Peut-être que le développeur de cette solution en était conscient, et que cela a même été documenté quelque part.
Et donc, dans ce cas, le problème n'est pas dans l'architecture mais dans le fait d'avoir mis en public des champs, ce qui n'est jamais une bonne idée pour des interfaces inter-module.
Dans ce cas de figure, plutôt que de chercher à faire remonter des erreurs via l'éditeur de lien qui a tendance à être un peu boite noire, c'est de mettre dans la chaîne de générations des outils de qualimétrie/validateur de code statique pour y coller des règles "custom" comme interdire l'utilisation de champs publiques dans les classes partagées ou qui dérive de classe partagées.
Il y a peut-être même déjà ce type de règle implémenté dans ce type d'outils, car votre cas d'usage est loin d'être très spécifique.

Citation:

---

Si j'ai bien compris l'intention du gars qui a mis ça en place, il y a trouvé un moyen commode de substituer les clients par des stubs dans l'exécutable de test.

---

Cela ressemble à une implémentation d'un mécanisme de DIP (Dependency Inversion Pattern), ce qui est très très bien.
Faudrait pas casser ce genre de machin, mais l'utiliser correctement. :aie:

Citation:

---

Ce qu'il a oublié, c'est que la classe abstraite repose sur des éléments de plus bas niveau (des signaux sigc) eux-mêmes bouchonnés lors du build de l'exécutable de test.

---

Ouais, bon, les signaux, ça fonctionne pas top avec la POO, mais aussi avec rien en général. ;)

Pour l'instant, ce que je "vois", c'est plus l'utilisation abusive de champs publics qu'une "vraie" faille dans la conception.
En quoi ça conception entre en conflit avec ces cochonneries de signaux ?

Citation:

---

mais bien de trouver un moyen de lever un warning comme la situation se présente.

---

Vous utilisez quoi comme outils de qualimétrie/validateur de code statique actuellement ?

Citation:

---

Car, à mon grand désarroi les cours de C++ passent trop de temps à présenter des syntaxes qu'on utilisera jamais plutôt que de parler des règles fondamentales d'architecture.

---

Le C++, c'est un langage informatique, et l'architecture, elle n'est pas fonction du langage, normalement.

L'exemple que vous proposez (fonctions de callback) est un cas d'école d'un certain nombre de Design Pattern mais, comme tout Design Pattern, il y a des compromis, et pour certain, c'est "pas de champs publics". :aie:

Donc, ma règle "pas de cycle" ne vaut qu'en l'absence de Design Pattern qui mitige ce problème avec des solutions éprouvées, mais qui impliquent très souvent des compromis (comme "pas de champs publics").

@kaitlyn, peux-tu nous donner les différences majeures d'approche de XPCOM par rapport COM, STP ? :calim2:

Salut bacelar,

Disons que XPCOM est aussi un modèle de composant. Techniquement il offre le même genre de service, mais il est plus léger, plus simple et plus flexible que COM. Peut-être l'équivalent d'un SQlite dans le domaine des SGBD.
L'exemple type de mise en oeuvre est Firefox, en fait ça a été fait pour. Je m'y étais intéressée quand j'ai voulu utiliser Firefox comme framework GUI au lieu de Copperspice ou WxWidgets.
Dis-moi si ça répond à ta question.

Oui, merci @kaitlyn.
Moi, j'avais surtout retenu que XPCOM était une version light de COM (pas de thread appartement, d'instanciation à distance, etc...).
Sur quel aspect XPCOM est plus souple que COM, STP ?

Salut,

XPCOM est complet, libre et multiplateforme, tu en fais ce que tu veux.
De l'autre côté, dans Microsoft COM tu n'as que les spécifications. Toute l'histoire des threads est gérée directement par l'OS. C'est aussi lui qui s'occupe de mettre en place des proxys pour que tes programmes communiquent et pas toujours de manière directe.
Donc si tu dois t'inspirer d'une techno de modèle de composant, je pense qu'il n'y a pas photo.