Bonjour,
Quand j’ai ouvert la fenêtre de l’éditeur d’image, Game Develop m’a affiché cette erreur :
[attachment=0]Capture.PNG[/attachment]
Ça se reproduit ou c’est passager ?
J’ai pas réessayé, mais cela c’est reproduit coup sur coup quan j’ai essayé d’ouvrir l’editeur. Chose bizarre, GD continue de tourner, je peux programmer, mais pas lancé d’apercu… → Compilation ?
Ca alors, une assertion !
Ce genre de message ne devrait pas s’afficher sur une version Release, ils devraient simplement être ignorés.
Bien sûr, seul 4ian peut savoir d’où ça vient vraiment, mais j’ai une petite idée.
4ian, il faudrait que tu ajoutes NDEBUG dans la liste “Defines” du target “Release” dans la fenêtre des “Build Options” dans Code::Blocks.
Ou alors tout simplement ajouter
#define NDEBUGquelque part quand tu n’es pas en Debug. Aussi, n’utilises pas les assertions et préfères l’utilisation d’un debugger comme GDB combinée à celle d’un profileur comme gprof.
J’utilise déjà évidemment un debugger quand le besoin s’en faire sentir. gprof ne fonctionne pas avec les bibliothèques partagées, ce qui est embêtant car GD en fait justement une utilisation massive ( De part les extensions mais aussi pour la plupart des fonctionnalités communes implementées dans GDL ).
Mais une assertion comme celle ci n’est pas forcément à cacher ( au contraire des “petites” assertions de wxWidgets qui la plupart du temps sont relative à des fichiers manquants ou à une petite erreur diverse ), car elle révèle un problème au niveau de la compilation avec LLVM. Je ne sais pas ce qui a pu la causer par contre.
Les assertions sont faites pour le debug, pas pour le release !
En release, une fonction qui commet une erreur devrait gérer elle-même l’erreur.
Et tu reconnaîtras également que les messages semi-Anglais semi-Français ne font pas très chic.
Quant aux assertions de wx, elles sont là parce que tu utilises la version debug de wx qui est plus lente, plus lourde, moins stable, et qui garde ce genre de chose qui n’est pas dans la version release…
Pour la cause, il s’agit d’une mauvaise utilisation des fonctions standard que tu fais dans un fichier nommé FileManager.cpp
Le mauvais côté des assertions, c’est que :
- Elles montrent à tout le monde l’organisation de ton logiciel (l’emplacement de tes sources)
- On aperçoit des morceaux de ton code source
- En utilisant “Recommencer”, quelqu’un qui sait habilement se servir d’un debugger JIT peut accéder à des parties entières de ton code source.
Non, je n’utilise évidemment pas wxwidgets en debug quand GD est compilé en release. Il suffit de regarder le nom des fichiers dlls de wxwidgets pour s’apercevoir qu’il n’y a pas le “d” caractéristique qui serait présent si jamais elles étaient compilés en debug.
Boarf, de la à ce que ça devienne une faille de sécurité, il y a un très grand pas.
Non, on aperçoit juste la condition de l’assertion.
Je suis curieux de savoir comment, c’est quand même du code compilé en mode release donc mis à part les noms (manglés en plus) des fonctions appelées, on va pas apercevoir grand chose, et surement pas le code original d’une fonction.
Pour wxWidgets, il y a surement moyen de redéfinir la fenêtre d’assertion.
Mais ici encore une fois, c’est pas une assertion de wxWidgets, mais une qui provient de LLVM ( qui utilise le mécanisme standard d’assertion, d’où le message en anglais et les boutons français sont dû au fait que le Windows utilisé est en français et que c’est des boutons standards automatiquement traduits. )
Le fichier FileManager.cpp ici appartient à LLVM, et si une assertion est levée ( de façon assez aléatoire il semble ), c’est parce que je dois surement mal utiliser LLVM à un moment, mais le problème reste difficile à cerner : Si ça ne dépendait que de moi, j’aimerai bien que les fonctions de LLVM utilisent moins d’assertion en cas d’échec, mais c’est pas le cas donc faut faire avec.
Et sinon, je peux faire quelque chose ou pas ?
Si tu penses que c’est dû à un jeu en particulier, tu peux me l’envoyer. Essaie sinon avec des jeux d’exemples de retirer/rajouter des images pour voir.
[…]
Il reste des symboles de débogage en effet, mais elles sont quand même compilées en release.
Non, plus depuis pas mal de temps.
[…]
Non, une bibliothèque compilée en debug va certes avoir des symboles de deboggage rendant l’executable plus lourd mais pas plus lent, mais aussi éventuellement du code propre au débuggage ( Genre des assertions supplémentaires définies avec du #if defined(DEBUG) … ) et sans optimisation, alors qu’une version compilée en release serait compilée sans le code propre au débuggage et avec les optimisations. Après, il y a toujours possibilité de garder les symboles des fonctions.
Par exemple, certaines bibliothèques qu’on peut compiler avec Cmake ( comme SFML ) permettent de choisir si l’on souhaite compiler en Debug/Release/RelWithDebugInfo, cette dernière cible compilant en Release ( optimisation à tout va activée donc en gros ) mais en gardant quelques symboles.
C’est très simple, j’ai compilé en Release avec les options par défaut. Plus sérieusement, je me tue à te dire qu’il n’y a rien de mal :
-La documentation de wxWidgets spécifie bien que “Starting with wxWidgets 2.9.1 debugging features are always available by default (and not only in a special “debug” build of the library)”.
-Les dlls n’ont pas le suffix “d” qui serait présent si elles étaient compilées en debug.