Discussion :

[RitoonL]

Bonjour,

mon programme crash à la fermeture ... windows cherche une solution au problème etc ...

J'ai donc executé le débugger de codeblocks mais sa sortie me laisse perplexe.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
Setting breakpoints
Debugger name and version: GNU gdb (GDB) 7.9.1
Child process PID: 10188
Program received signal SIGSEGV, Segmentation fault.
In std::basic_ostream<wchar_t, std::char_traits<wchar_t> >::flush() () ()
Continuing...
Program received signal SIGSEGV, Segmentation fault.
In std::basic_ostream<wchar_t, std::char_traits<wchar_t> >::flush() () ()
Continuing...
[Inferior 1 (process 10188) exited with code 030000000472]
Debugger finished with status 0

J'ai pensé à un problème de pointeur, mais j'ai bien fait attention à détruire les objets créés dynamiquement, et remettre les pointeurs à la valeur nullptr en détruisant les objets créées de manière statique.
Je ne comprend pas le message du debugger à propos d'ostream. Du coup je ne sais pas trop ou chercher dans le code pour régler le problème.

Si quelqu'un aurait la bonté de me mettre sur la voie, une méthodologie pour pouvoir trouver d'où ça viens car c'est pour l'instant assez obscur pour moi.

Je voudrais bien vous copier des parties de mon code, mais je ne sais pas trop quoi ...

Merci d'avance ...

[dalfab]

Bonjour,

L'erreur que tu as correspond à un objet de type std::wstream (par exemple std::wcout) qui vraisemblablement au moment de sa destruction n'est pas cohérent, par exemple il a déjà été détruit et on cherche à le "re-détruire", ou bien il a été "écrasé" en utilisant un pointeur invalide.
Une de tes phrases m'amène à une interrogation "remettre les pointeurs à la valeur nullptr en détruisant les objets créées de manière statique". a
Ai-je compris? On ne doit surtout pas détruire les objets statiques! Ils sont statiques donc créés et détruits par le système.
On ne devrait pas non plus détruire les objets dynamiques, mais plutôt les gérer avec des "pointeurs intelligents" qui eux s'occupent des destructions mieux que nous. Mais si tu maîtrises, tu peux gérer toi même tes destructions.

[RitoonL]

merci de ta réponse ...

J'ai complétement oublié, mais en fait l'objet que je créai statiquement, je l'avais changé pour l'instancier avec new, je le détruit à la fermeture avec Delete, j'avais juste zappé avoir changé ça. Nous avons (nous car nous sommes 2 sur le projet) préféré gérer les destructions sans utiliser de pointeurs intelligents car on recherche une gestion fine, sachant qu'on a un vector d'objet qu'on doit trier à chaque fois qu'une instance est créée, mais aussi quand ils sont détruits par l'utilisateur du programme. On parcours le vecteur à la fermeture du programme pour détruire tous les objets avec Delete.

Je remet certains pointeurs à nullptr dans le destructeur, ces pointeurs sont des widgets TGUI, je ne sait pas si c'est réellement nécessaire, mais j'ai préféré le faire pour éviter des memory leaks.

Concernant ta réponse qui conforte ce qu'on a fini par reussir a analyser, je pense qu'on a trouvé le problème, en ayant isolé la fonction qui fait planter.

on "lit" les objets pour envoyer un flux DMX512 via le réseau et on a juste omis d’arrêter cette lecture avant de détruire les objets. Il y a donc de grandes chances que le problème vienne du fait que pendant quelques millisecondes, le programme tente d’accéder à des objets qui ont été détruits, avant que le programme ne ferme définitivement. On va déjà changer ça voir si ça résout le problème.

Le projet est ambitieux pour nos compétences, on apprend en faisant, donc on se heurte a des petits trucs comme ça qu'on met du temps a réussir à analyser.

Merci pour ta réponse en tout cas.