Comportement bizarre de mon exécutable.

Salut les GTK+3,

J'ai un comportement bizarre et je crois bien que c'est lié a GTK+3 ou a ma manière de compiler.

Le problème est si je renomme le dossier ou que je déplace mon exécutable le programme plante au démarrage erreur de pointeur Glib (j'ai pas penser au traceback exact, je vous le fournirai ultérieurement).

Et cela est plutôt bizarre car je n'utilise que des chemins relatifs pour les dépendances.

Ma manière de compiler:
====================

La compilation est séparer d'un coté une library personnel de l'autre ma GUI et ce qui fait le lien le contrôleur.

La library peut être de forme library static ou fichier objet (*.o).

Le tout passé en ligne de commande dans un fichier Makefile.

Je ne sais absolument pas du tout pourquoi cela fait ça ???

J'ai un peu regarder du côté de Gtk::Application (car j'utilise Gtk::Main normalement) et j'ai vue que une application est|peu être limité en termes d'actions et de comportement selon son type, mais je ne comprends toujours pas ce qui se passe avec mon exécutable.

Merci pour vos réponses éclairées.

PS: ce n'est pas la faute de library static car ça fait pareil avec un fichier objet à la place. Et je suis sous Linux.

Je n'arrive pas à comprendre....

Tu as ton répertoire de travail avec ton exécutable. Ça marche.
Tu renommes ce répertoire et ton exécutable plante ? Et si tu compiles après avoir renommé, ça donne quoi ?

Peux-tu essayer de faire du débogage ? Codeblocks pourrait être utile pour ça, mais il faudrait alors reconfigurer ton projet.

Moi non plus je ne sais pas ce qui se passe.

Pour répondre a tes questions:

J'ai une arborescence dont un dossier contient mon exécutable et toutes ces dépendances (images, library static personnel, etc...)
.
Et donc si je renomme ce dossier ou un dossier parent d'ailleurs résultat mon application plante avec le traceback suivant:

Citation:

---

terminate called after throwing an instance of 'Glib::FileError'
make: *** [exec] Abandon (core dump créé)

---

Que je compile le code avant ou après le renommage.

D'ailleurs je n'ouvre aucun fichier avec gtkmm au démarrage mais avec OpenCV (3) (qui dépends de GTK+3) si.

Coté débogage je ne l'ai jamais pratiquer, et je travaille en ligne de commande pour compiler aider d'un Makefile.

Je pense que le problème vient de gtkmm mais peut aussi venir des entrailles de make ou encore de OpenCV (parce que basé en partie sur GTK+3).

Mais je ne sais absolument pas quoi faire nie d'ou vient exactement le problème.

Toute aide est le bienvenue.

Merci pour vos réponse éclairées.

Ca ressemble quand même à la tentative avortée d'ouverture d'un fichier dont le chemin est incorrecte. Peut-être que tu ne testes pas le retour d'une fonction qui manipule un fichier. Si le résultat est indéterminé et que tu tentes par la suite de libérer l'espace mémoire normalement alloué tu te retrouves avec un segfault.

Regarde de plus prés tous les chemins qui seraient codés en dur dans ton code source.

Si tu ne peux pas faire de pas à pas, gerald3d m'a conseillé gdb :

Citation:

---

Envoyé par gerald3d

je ne comprends pas pourquoi tu mets à NULL retour. Ce pointeur pointe toujours sur un espace alloué. Tu vas avoir une fuite mémoire ici.

Pour Gdb tu peux l'utiliser tout simplement. Tu ajoutes -g lors de la compilation. Puis tu lances ton exécutable avec Gdb : gdb mon_programme.
Tu accèdes alors à un prompt. Tu lances depuis ce prompt "run". Ton programme se lance. Une fois qu'il a planté tu reviens au prompt. Tu peux alors taper "where" pour savoir où le programme a planté. Il te donnera la ligne exacte dans ton code source. Ensuite tu tapes toujours dans le prompt "continue" ce qui va terminer ton programme qui pour l'instant est bloqué. Enfin tu tapes "quit" pour sortir de Gdb.

Il existe bien d'autres possibilités mais cette première utilisation te donne l'essentiel : la ligne qui pose problème.

---

Ça te dira où ça plante dans ton code.

Merci pour vos réponses,

ne connaissant gdb que des livres et non de la (vrai) pratique je vais essayer la recette proposer.

Information supplémentaire:
j'ai compiler moi-même OpenCV d'après les sources et quand j'ai un traceback de OpenCV il fait référence au chemins du dossier temporaire que j'ai utiliser pour la compilation ???

Pour dire qu'on collectionne les anomalies...

Merci.

Ho que oui gdb,

grâce a vos conseils éclairées j'ai découvert ce qui clochait et gerald3d avait raison c'était bien la faute une de ces sal*þris de chemin absolue.

C'est la première fois que j'utilise gdb en situation réel en j'aurai jamais trouver d'abords sans vous et gdb.

Même une utilisation rudimentaire, avec un minimum est sacrément efficace pour trouver des bugs comme celui la et donc debugger.

Je vais essayer de prendre le réflexe quand je trouve pas avec des printf enfin quand c'est plus grave...

Merci beaucoup, vous avez résolu le problème et je me coucherai moins bête ce soir.