Le debugger ne donne pas qu'une valeur d'exception : pile d'appels, valeurs des variables, des paramètres, etc..., ainsi que les codes sources correspondants.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Ogre3D, c'est de l'Open-Source et c'est fait en C++.
C'est pas parce que c'est pas "votre" code que vous y êtes aveugle. Rassurez-vous, ça rend pas aveugle de lire du code qu'on n'a pas écrit.
C'est du code C++ et vous devriez savoir le décoder et donc trouver la source du problème.
Le code montré dans la copie d'écran, c'est la partie qui lance l’exception (le "haut" de la pile d'appels).
Vous n'avez qu'à décoder le code C++ pour en connaitre l'origine.
Ici, c'est vraisemblablement une MACRO/code utilitaire pour construire et lancer les exceptions.
Vous n'avez qu'à savoir d'où vient la valeur dans la variable "code".
Comme Ogre, c'est pas fait par des branquignoles, il y a toutes les chances que cette valeur vienne d'un paramètre de la MACRO ou de la fonction utilitaire.
Pour remonter la pile d'appels et ainsi aller à la source de cette valeur et donc du problème, il suffit d'utiliser l'onglet "Pile des appels" (merci captain obvious), en bas à gauche de la fenêtre en bas à droite.
En cliquant sur les différentes lignes affichées dans cette fenêtre, vous passerez du code source d'une fonction au code source de la fonction qui a appelé, directement ou indirectement, les autres fonctions, plus "haut" dans la pile. La plus en haut est la dernière à avoir été appelée.
Le debugger mais le curseur sur la ligne de la fonction qui appel la fonction un grand au-dessus dans la pile d'appels.
P.S.: Il m'a fallu au moins 10 fois plus de temps pour rédiger ce message que de temps pour remonter "effectivement" à la source du problème.
P.P.S.: Vous êtes en Release, commencez par chercher à corriger en Debug.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Je suis passé en débug, l'erreur est maintenant une bad_alloc et quand je vais dans la pile d'appel, je n'ai pas le fichier en dessous de la position de mon curseur :
Bon, bin, un bad_alloc, c'est 99% du temps le fait de faire un new/malloc avec une taille à la con, genre un -1 qui se transforme en une énorme valeur en passant en unsigned.
Mais en regardant la demi ligne du bas de la pile d'appel de votre copie d'écran, ça parait encore plus trivial. (suspenssss !)
>je n'ai pas le fichier en dessous de la position de mon curseur
Si vous n'avez pas vous même compilé OgreBites.dll ou correctement configurer votre serveur de symbole/le configuration de vos projet au niveau de la génération des pdb, c'est normal.
Mais les détails affichés dans la pile d'appels montrent que le débogueur a accès aux pdb de OgreBites.dll et/ou de la C++ Runtime associée.
Faudrait peut-être penser à installer les sources de la C-Runtime et de la C++-Runtime dans Visual Studio (ça doit être une des options à la con dans l'instalateur/usine à gaz de Visual Studio). (en plus de celles d'Ogre3D même si vous ne faites qu'utiliser les Dll).
Mais bon, en regardant cette demi ligne coupée dans la fenêtre de la pile d'appel, on voit un appel à "std::string::assign".
Si ce type d'appel arrive à une exception "bad_alloc", il y a 99,99999999% de chance, minimum, que "vous" lui avez donné de la mer.. en paramètre.
N'hésitez pas à descendre dans la pile pour arriver à un endroit correspondant à votre code et qui correspond à l'appel qui a déclenché le problème.
Il y a gros à parier que ses paramètres sont foireux ou que les objets utilisés pour faire le boulot de cet appel sont dans un état merdique.
Vous devriez assez facilement voir d'où vient le problème.
Si le code source de la STL vous fait mal aux yeux, c'est normal et ne cherchez pas de bug dedans, c'est plus qu’improbable.
C'est votre manière de l'utiliser (ou Ogre3D) qui la fait "planter".
Donc, soit vous descendez directement dans la pile d'appel pour atteindre votre code et analyser les paramètres que vous donnez à la primitive ; soit vous commencez par le haut de la pile où vous connaissez le paramètre qui est aux fraises et vous descendez vers l'appelant en voyant d'où vient le paramètre foireux dans le code de l'appelant et vous descendez récursivement jusqu'au bug (à 99%de chance dans votre code).
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Pourrais tu déjà nous montrer la définition de ta classe App, pour que l'on sache à quoi correspond OgreBites::ApplicationContext dans ton code
Pourrais tu aussi nous montrer le code qui crée une instance de ta classe App?
En attendant, peut-être pourrais tu déjà laisser le constructeur "par défaut" de OgreBites::ApplicationContext faire son travail pour voir si tout se passe bien?
Dans le pire des cas, vu que tu utilises une version récente du compilateur, tu devrais plutôt utiliser les acollades pour pour l'instanciation de OgreBites::ApplicationContext, voire, faire un appel explicite au constructeur adéquat pour la chaine de caractères, quelque chose qui pourrait ressembler à
PS: es tu sur que la version de Ogre que tu utilises a bien été compilée avec le même compilateur, dans la même version que celui que tu utilises?
- Edité par koala01 3 mars 2021 à 11:51:56
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Je ne vois pas de constructeur qui prend en paramètre un vieux pointeur tout pourri "char *" qu'implique votre utilisation toute pétée d'une chaîne de caractère en dur.
Je ne vais pas chercher à comprendre quel mécanisme foireux a réussi à faire passer cette ignominieuse valeur en dur pour une "const Ogre::String &" et je vous conseille d'en faire de même, en fournissant une référence constante sur une "Ogre::String" et pas une chaîne de caractère C stockée aléatoirement entre la section ".code" ou la section ".data" de votre exécutable.
(Pensez à régler les warning de votre compilateur et à les lire dans les résultats de compilation, SVP)
>Et je ne peux pas accèder aux fichiers de la piles d'appel.
Déjà expliqué dans mes précédents post, je crois.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Pourrais tu déjà nous montrer la définition de ta classe App, pour que l'on sache à quoi correspond OgreBites::ApplicationContext dans ton code
Pourrais tu aussi nous montrer le code qui crée une instance de ta classe App?
#pragma once //App.h
#include <iostream>
#include <Ogre.h>
#include <Bites/OgreApplicationContext.h>
#include <RTShaderSystem/OgreShaderGenerator.h>
class App : public OgreBites::ApplicationContext, public OgreBites::InputListener
{
public :
App();
void setup();
bool keyPressed(const OgreBites::KeyboardEvent& evt);
};
#pragma once //main.cpp
#include "App.h"
int main(int argc, char* argv[])
{
App app;
app.initApp();
app.getRoot()->startRendering();
app.closeApp();
return 0;
}
koala01 a écrit:
En attendant, peut-être pourrais tu déjà laisser le constructeur "par défaut" de OgreBites::ApplicationContext faire son travail pour voir si tout se passe bien?
Même erreur : std::length_error
bacelar a écrit:
(Pensez à régler les warning de votre compilateur et à les lire dans les résultats de compilation, SVP)
J'ai plus de 500 warnings dont la majorité est du type :
AvertissementC26495La variable 'Ogre::AnimableValue::<unnamed-tag>::mBaseValueInt' n'est pas initialisée. Initialisez toujours une variable membre (type.6).TestOgre3DC:\Users\Utilisateur\Documents\Prog\Lib\Ogre3D\include\OGRE\OgreAnimable.h142
bacelar a écrit:
>Et je ne peux pas accèder aux fichiers de la piles d'appel.
Déjà expliqué dans mes précédents post, je crois.
Mais j'ai installé le C-runtime dans l'installateur vs.
Même si le code de @koala01 a une erreur (il y a une parenthèse ouvrante à la place d'une accolade ouvrante), c'est pas une raison pour ne pas suivre ses très bons conseils.
Déjà qu'on n'est en mode "good cop/bad cop", et c'est moi qui tient la matraque, si vous suivez pas les conseils du "good cop", ça va charcler.
Si vous avez suivi son conseil de prendre le constructeur par défaut de "OgreBites::ApplicationContext" et que vous vous prenez un "std::length_error", ça sentirai bien une incompatibilité entre Ogre3D et la C-runtime utilisé par le compilateur. C'est possible mais il est aussi possible que vous ayez mal compris les instructions de @koala01. Sans le code, impossible de trancher.
Le conseil d'utiliser un "constructeur" de "OgreBites::String" explicitement (conseil de @koala01 et aussi le mien) devrait plus vous prémunir contre ces incompatibilités potentielles. Donc essayez cette technique, SVP.
>J'ai plus de 500 warnings dont la majorité est du type :
Heu, vous voulez qu'on vous tienne la main pour corriger ces warning ?
Bacelar te l'as pourtant dit: mon doigt a glissé de l'accolade vers la parenthèse dans le code que je te présentais (et que je vais donc corriger). Il fallait lire (et utiliser, du coup)
te donne toujours le même résultat, c'est qu'il y a -- de toutes évidences -- un problème d'incompatibilité entre le système qui a été utilisé pour compiler la version de Ogre que tu utilises et ton compilateur.
A vrai dire, il en suffit parfois de pas grand chose pour que cette incompatibilité survienne, si bien qu'une des premières choses à faire -- après avoir essayé avec un projet le plus basique possible, histoire de s'assurer que ce n'est pas tout simplement le code que l'on a écrit qui est foireux (ce qui arrive très régulièrement, surtout lorsque l'on débute) -- c'est sans doute d'essayer de compiler soi-même une version récente de la bibliothèque que l'on souhaite utiliser, directement avec le compilateur que l'on s'apprête à utiliser pour notre projet
Et, comme, en plus, ogre utilise CMake pour sa propre configuration, cela ne devrait vraiment pas être compliqué à réaliser
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
et j'ai aussi essayé d'enlever le "const" et/ou la & et de remplacer "OGRE_VERSION_NAME" par du texte lambda entre guillemets...
Il me reste deux m^me warnings dont je ne comprends pas comment les résoudres :
Avertissement C4275 interface non dll class 'Ogre::MaterialManager::Listener' utilisée comme base d'une interface dll class 'OgreBites::SGTechniqueResolverListener'
dragonjoker a écrit:
Perso, j'utilise vcpkg pour mon moteur de jeu basé sur Ogre3D, et n'a plus de problèmes.
J'ai essayé, j'ai eu beaucoup de mal à installer Ogre avec, mais une fois qu'il a trouvé la bibliothèque, et aprs avoir dû corriger les chemin d'include des fichiers ogre, il me renvoie 15 erreurs LNK2019 alors que j'ai bien les dll dzns mon dossier.
La présence des dll ou non dans un quelconque répertoire du disque n'a strictement aucun rapport avec les erreurs ou warnings de compilation ou d'édition des liens. Seuls comptent les fichiers d'imports des dll: en général .lib avec Visual Studio et .dll.a pour MinGW (mais parfois aussi .lib).
Les dll n'ont d'importance qu'à l’exécution du programme.
Oui je n'ai pas mis les .lib dans mon projets parce ce qu'il y a marqué (je l'ai vu sur plusieurs sites) qu'avec vcpkg pas besoin de faire de modif dans le projet vs.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Si vous ne trouvez plus rien, cherchez autre chose.
Si vous ne trouvez plus rien, cherchez autre chose.