Exceptions sous Linux à partir d'un objet partagé (.so)

Question

J'ai un programme de test appelé ftest. Il charge les fichiers .so qui contiennent des tests et exécute les tests qu’il trouve. L'un de ces tests charge et exécute un .so contenant un pilote de base de données Postgres pour notre système d'exploitation / RM.

Lorsque le pilote PostgreSQL lève une exception définie dans ce fichier .so (ou à laquelle il est lié, mais ftest n'est pas lié) et est intercepté par le framework de test, le destructeur d'exceptions déclenche un segfault.

Cette erreur de segmentation se produit chaque fois que l'exception compilée se trouve dans un fichier .so chargé dynamiquement (à l'aide de dload).

Ce genre de chose fonctionne bien sous Windows, qui a la même architecture. Nous ne voulons pas vraiment nous limiter à n'utiliser que des exceptions issues des bibliothèques principales. Les compléments devraient être libres de créer leurs propres classes d'exceptions et de les gérer normalement.

Les exceptions sont des sous-classes de std :: exception. Parfois, les exceptions peuvent être définies dans des bibliothèques (telles que libpqxx), ce qui signifie que les exceptions sont parfois aussi hors de notre contrôle.

Les exceptions sont levées en utilisant quelque chose comme:

throw exception_class( exception_arguments );

Et sont pris avec:

catch ( std::exception &e ) {
    // handler code
}

Existe-t-il une option spéciale du compilateur pour que cela fonctionne? Devons-nous passer à des exceptions via throw new exception_class( args ) (nous ne voulons pas vraiment faire cela)?

Answer 1

En supposant que vous utilisiez gcc -

Ajoutez -Wl, -E lorsque vous générez l'exécutable appelant dlload (). Cela exporte tous les symboles d’informations de type de l’exécutable, ce qui devrait permettre au RTTI (lorsqu’il intercepte l’exception) de fonctionner correctement.

VC ++ utilise des comparaisons de chaînes pour faire correspondre typeinfo, ce qui entraîne un ralentissement de dynamic_cast < > etc mais binaires plus petits. g ++ utilise le pointeur compare.

J'ai rencontré le même problème lorsque j'essayais d'utiliser des classes d'interfaces virtuelles pures implémentées dans un fichier .so chargé.

Quelques articles sur le sujet circulent également sur le net.

espérons que cela aide, Hayman.