Accéder au contenu.
Menu Sympa

technique - Re: [April technique] bogue dlopen croisé dans RefPerSys (commit 8553aeaa8442)

Objet : Liste pour les discussions techniques (liste à inscription publique)

Archives de la liste

Re: [April technique] bogue dlopen croisé dans RefPerSys (commit 8553aeaa8442)


Chronologique Discussions 
  • From: Just an Illusion <illusion_to_net AT yahoo.fr>
  • To: Basile Starynkevitch <basile AT starynkevitch.net>, technique AT april.org
  • Subject: Re: [April technique] bogue dlopen croisé dans RefPerSys (commit 8553aeaa8442)
  • Date: Sat, 7 Aug 2021 09:55:10 +0200

Bonjour à tous,
Toujours destinataire de la synthèse technique de cette ancienne liste de diffusion, je n'ai plus malheureusement le bon niveau d'expertise pour identifier la cause source du défaut.
N'ayant plus la référence du site de la Liste, ni mes accès (mot de passe oublié, car plus utiliser depuis au moins 15-20 ans)

Je note néanmoins les points suivants qu'il me paraît nécessaire de peut-être résoudre préalablement:
*Point#1 -  Il y a le message "..the loop to display object is incomplete..", j'ai donc l'impression que le code dans le dépôt n'est pas dans un état 'stable'; causes possibles ?!? peut-être un problme lors du commit (donnée incomplète ou corrompue).
En regardant rapidement sur internet, j'ai trouvé cet échange qui abonde dans ce sens: https://github.com/microsoft/azuredatastudio/issues/13873; une solution a vérifié: vérifier l'état du merge côté Dépôt GIT et voire à fusionner les modifications

*Point#2 - Il y a le message ".../tempgui-qrps.so: undefined symbol: _ZN17Rps_PayloadStrBuf12clear_bufferEv..", la cause origine semble claire: dans la bibliothèque 'tempgui-qrps', il doit exister un appel direct (ou par héritage) qui nécessite le 'symbole' '_ZN17Rps_PayloadStrBuf12clear_bufferEv', or il n'est pas (ou plus) présent.
Il peut s'agir d'un cas typique de gestion incorrecte dans l'ordre d'appel des librairies (et plus généralement des dépendances), ou l'utilisation d'une librairie pour laquelle il a été procédé à une évolution et donc disparition du symbole (plus présent en 'export'); le code d'appel n'ayant pas été mis à jour et lors de la compilation, il n'y a pas de résolution pour la phase de 'link'.
Généralement la meilleur façon de régler ce type de situation est donc d'identifier l'arbre d'appel des différentes bibliothèques (*.so), puis d'identifier quelle bibliothèque contient le 'symbole'.
Une fois la bibliothèque identifiée, il faut vérifier si d'autres symboles ne sont pas 'remplacer' via des bibliothèques plus récentes et donc définir l'ordre du LD_LIBRARY_PATH (rappel: pour chaque 'symbole' le parcours des chemins s'arrête à la première occurrence 'correspondante' trouvée)

Côté Unix/Linux, il existe plusieurs commandes 'natives' permettant de retrouver la liste des symboles 'exportés' dans une application ou une librairie; mais je ne me les rappelle plus la liste exhaustive.J'ai néanmoins trouver, pour exemple, des propositions sur: https://unix.stackexchange.com/questions/103744/find-where-is-a-shared-library-symbol-defined-on-a-live-system-list-all-symbol

Personnellement, j'appliquerais la procédure de diagnostic suivante:
Avec une version précédente, j'identifierais les librairies candidates à l'aide de la commande standard 'ldd': ex. >ldd refpersys --Qt -AGUI,WEB
Ensuite, et pour chaque librairie identifiée, j'appliquerais l'identification des symboles comme proposé: nm, readelf, scanelf (, autres)..
Une fois la librairie identifiée, je vérifierais si elle n'est pas masquée par une autre (i.e. définie avant dans le chemin de parcours du LD_LIBRARY_PATH) ou manquante (ex. LD_LIBRARY_PATH non surchargé dans l'environnement Utilisateur). Rappel et par défaut, si non surchargée par la configuration Système(wise), la valeur de garde intègre essentiellement les dépôts suivant (ordre à confirmer): /lib, /lib64, /usr/lib, /usr/lib64 (et si existant: /usr/local/lib, /usr/local/lib64, /usr/share/lib, /usr/share/lib64, /opt/lib, /opt/lib64,/opt/local/lib, /opt/local/lib64, /opt/share/lib, /opt/share/lib64). Cf. la documentation du File System Hierarchy Linux pour plus de détails: >man fsh

Cdt,
JaI

Le 29/07/2021 à 21:40, Basile Starynkevitch a écrit :

Bonsoir à tous,

RefPerSys est un logiciel libre d'intelligence artificielle symbolique (sous licence GPLv3+) sous Linux. La philosophie, c'est méta-connaissances déclaratives (vous lirez avec profit le livre: Méta-connaissances, futur de l'Intelligence Artificielle  ISBN  2-86601-247-X, Hermès 1997) auto-génération du système (j'en suis encore loin, mais grâce à d'autres je m'en rapproche...).

Pour les curieux, voir les exposés en https://afia.asso.fr/journee-hommage-j-pitrat/ et surtout, lire le dernier livre de Pitrat (en anglais) Artificial Beings : the Conscience of a Conscious Machine ISBN-13: 978-1848211018. Ce livre se lit bien et ne nécessite pas de connaissances informatiques poussées.

Le code C++ (actuellement écrit à la main, hélas; je voudrais en générer davantage) de RefPerSys (commenté en anglais) est en https://github.com/RefPerSys/RefPerSys

et ce message concerne le git commit 8553aeaa8442

L'idée directrice (insuffisamment suivie) est de traduire un formalisme de règles (systèmes experts) en du code généré C++, actuellement utilisant Qt5. L'état persistant de RefPerSys est stocké dans des fichiers textuels (sous persistore/ ...) dans un format inspiré de JSON.

La configuration de RefPerSys est artisanale: un banal Makefile, avec un fichier inclus $HOME/.refpersys.mk qui contient par exemple

# file ~/.refpersys.mk
RPS_BUILD_CC= /usr/bin/gcc-10
RPS_BUILD_CXX= /usr/bin/g++-10

(on peut remplacer gcc-10 par gcc-11 ou clang-12, etc...)


Après avoir compilé RefPerSys (par un make -j7 refpersys && make all) je le lance avec ./refpersys --Qt -AGUI,WEB et j'obtiens (depuis un commit ou deux) systématiquement l'erreur:

rimski.x86_64 ~/RefPerSys 20:53 .0 % ./refpersys --Qt -AGUI,WEB


*** RefPerSys INFORM: main_rps.cc:754: <int main(int, char**)>
 !-!-! starting RefPerSys !-!-! ./refpersys process 10298 on host rimski
... gitid 8553aeaa84429a15 built Thu 29 Jul 2021 08:53:24 PM MEST (main@0x555c2cba177d) interactive mode (3 jobs)

make: Entering directory '/home/basile/RefPerSys'
make: Leaving directory '/home/basile/RefPerSys'
** RefPerSys INFORM! main_rps.cc:586: void rps_check_mtime_files() rps_check_mtime_files: did make -t -C /home/basile/RefPerSys -q objects successfully
** RefPerSys INFORM! store_rps.cc:749: void Rps_Loader::load_all_state_files() loaded 1 space files in second pass with 196 objects and 0 todos

** RefPerSys INFORM! store_rps.cc:2721: void rps_load_from(const string&) rps_load_from completed
... from directory /home/basile/RefPerSys with RefPerSys built Thu 29 Jul 2021 08:53:24 PM MEST
 lastgitcommit 8553aeaa8442 more code in RpsTemp_ObjectBrowser::refresh_object_browser - the loop to display object is incomplete
 md5sum 45449edd9382713d22f67e2b8edad88b
 loaded 196 objects in 0.004 elapsed, 0.004 cpu seconds
 so 22.165 elapsed µs/ob, 22.161 cpu µs/ob, in 7434 memory words.
=============================================================================




*** RefPerSys INFORM: main_rps.cc:1120: <void rps_run_application(int&, char**)>
 rps_run_application: start of ./refpersys
.. gitid 8553aeaa84429a15d52d961e632210c93dc1f8ae+
.. build timestamp Thu 29 Jul 2021 08:53:24 PM MEST
.. last git commit 8553aeaa8442 more code in RpsTemp_ObjectBrowser::refresh_object_browser - the loop to display object is incomplete
.. md5sum 45449edd9382713d22f67e2b8edad88b
.. in /home/basile/RefPerSys
.. on host rimski pid 10298


** RefPerSys INFORM! main_rps.cc:1675: bool rps_set_debug_flag(const string&) setting debugging flag GUI
** RefPerSys INFORM! main_rps.cc:1675: bool rps_set_debug_flag(const string&) setting debugging flag WEB


*** RefPerSys INFORM: main_rps.cc:1138: <void rps_run_application(int&, char**)>
 rps_run_application did set debug after load to GUI,WEB

** RefPerSys INFORM! main_rps.cc:1206: void rps_run_application(int&, char**) rps_run_application will do Qt from pid 10298 on rimski so make tempgui-qrps.so
make: 'tempgui-qrps.so' is up to date.


** RefPerSys FATAL! main_rps.cc:1214:: dlopen tempgui-qrps.so failed : ./tempgui-qrps.so: undefined symbol: _ZN17Rps_PayloadStrBuf12clear_bufferEv

RPS FATAL:
 RefPerSys gitid 8553aeaa84429a15d52d961e632210c93dc1f8ae+,
     built timestamp Thu 29 Jul 2021 08:53:24 PM MEST,
     on host rimski, md5sum 45449edd9382713d22f67e2b8edad88b,
     elapsed 0.068, process 0.022 sec
[001] main_rps.cc:1214°: rps_run_application @0x555c2cb9f84b
[002] main_rps.cc:768°: main @0x555c2cba242d
===== end fatal error at main_rps.cc:1214 ======
--------------------------------/ main_rps.cc:1214
zsh: IOT instruction (core dumped)  ./refpersys --Qt -AGUI,WEB


Ca fait plusieurs jours que je n'arrive pas à comprendre cette erreur, et à corriger mon bogue.

Avez vous des idées, une stratégie de déboguage? Je ne suis pas un expert de binutils. Je suis sensé avoir été un expert de GCC.


Librement.

PS. Je cherche aussi des "mécènes", concrètement des partenaires pour des soumissions ITEA ou HorizonEurope. Le site http://refpersys.org/ donne des références possibles d'appels à projets dans le cadre HorizonEurope, et des futures applications.


NB: je cherche aussi des relecteurs pour un papier en cours de soumission à ROIA (revue ouverte d'intelligence artificielle). Contactez moi pour en obtenir le PDF actuel.

--

Basile Starynkevitch                  <basile AT starynkevitch.net>
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/




  • Re: [April technique] bogue dlopen croisé dans RefPerSys (commit 8553aeaa8442), Just an Illusion, 07/08/2021

Archives gérées par MHonArc 2.6.19+.

Haut de le page