Dois-je m'inquiéter au sujet de “saut Conditionnel ou déplacer dépend non initialisée valeur(s)”?
Si vous avez utilisé Memcheck (à partir de Valgrind), vous allez probablement être familier avec ce message...
Saut conditionnel ou déplacer dépend de la valeur non initialisée(s)
j'ai lu à ce sujet et il simplement se produit lorsque vous utilisez une valeur non initialisée.
MyClass s;
s.DoStuff();
Cela fonctionne parce que s
est automatiquement initialisé... Donc si c'est le cas, et il fonctionne, pourquoi ne Memcheck me dire que c'est non initialisée? Le message devrait-il être ignoré?
Peut-être que j'ai mal compris où l'erreur a été de diriger moi. À partir de la Valgrind manuel, le erronée extrait est...
int main()
{
int x;
printf ("x = %d\n", x);
}
Cependant, dans mon code, je ne peux pas voir quoi que ce soit. J'ai remarqué cependant que la fonction en haut de la trace de la pile Memcheck me montre est une fonction virtuelle; cela pourrait-il être quelque chose à faire avec elle?
==14446== Conditional jump or move depends on uninitialised value(s)
==14446== at 0x414164: vimrid::glut::GlutApplication::FinishRender() (GlutApplication.cpp:120)
==14446== by 0x422434: vimrid::demos::filterdemos::FilterDemo3::Render() (FilterDemo3.cpp:260)
==14446== by 0x412D3D: vimrid::VimridApplication::UpdateAndRender() (VimridApplication.cpp:93)
==14446== by 0x4144BA: vimrid::glut::GlutApplication::glutHandleDisplay() (GlutApplication.cpp:201)
==14446== by 0x41486A: vimrid::glut::GlutApplication::glutCallbackDisplay() (GlutApplication.cpp:277)
==14446== by 0x54D9FAA: (within /usr/lib64/libglut.so.3.8.0)
==14446== by 0x54DDA4A: fgEnumWindows (in /usr/lib64/libglut.so.3.8.0)
==14446== by 0x54DA4A3: glutMainLoopEvent (in /usr/lib64/libglut.so.3.8.0)
==14446== by 0x54DAEB5: glutMainLoop (in /usr/lib64/libglut.so.3.8.0)
==14446== by 0x413FF8: vimrid::glut::GlutApplication::Run() (GlutApplication.cpp:112)
==14446== by 0x41249D: vimrid::Launcher::runDemo(vimrid::VimridSettings&) (Launcher.cpp:150)
==14446== by 0x412767: vimrid::Launcher::Launch(int, char**) (Launcher.cpp:62)
Mise à jour 1:
J'ai pris un coup d'oeil à GlutApplication.rpc:120, et il semble que la variable non initialisée a été transmis à une fonction sur cette ligne. Simple!
Hmm, je pense que j'ai supposé trop ici, j'ai mis une ligne que je ne pense pas que c'est ce qui est à l'origine du problème... C'est la FinishRender fonction (je crois)...
OriginalL'auteur Nick Bolton | 2009-04-19
Vous devez vous connecter pour publier un commentaire.
Pouvez-vous poster un exemple plus complet? Il est difficile de voir comment il y aurait cette erreur avec une certaine forme de goto ou de flux de modification de déclaration.
J'ai le plus souvent les voir cette erreur dans le code suivant
Ce code est fondamentalement erronée. La raison en est que, même si la s2 est un constructeur, il n'est pas exécuté si someCondition est vrai. L'instruction goto va sauter sur l'initialisation et à la dernière ligne du programme s2 sera initialisé et essentiellement du point à la poubelle.
MODIFIER
Vous pouvez également consulter cette page qui donne des conseils sur la façon de déchiffrer cette erreur valgrind
https://computing.llnl.gov/code/memcheck/#deciphering4
Additif
Une autre cause commune pour ce que je viens de trouver, c'est quand vous passez au-dessus de certaines constantes entières à un variadic fonction, qui sont mis sur la pile des entiers, mais lorsque le destinataire de l'appel, il reçoit en tant que longs, vous avez un problème sur les ordinateurs 64 bits.
J'étais presque sur le point d'abandonner et il suffit de considérer valgrind être stupide, alors je me suis rendu compte que le simple moulage long corrige.
Donc mon résultat est: prendre ce message au sérieux.
...en supposant que Maclasse a défini par l'utilisateur, constructeur, bien sûr.
Il peut être légal de C++ - si MyClass est un type POD puis c'est légal C++ (même si c'est mauvais).
oui, vous avez raison, c'est PODness qui est de la question plutôt que de ce que j'ai dit à propos d'un constructeur
OriginalL'auteur JaredPar
Vous pouvez ajouter le drapeau
--track-origins=yes
à valgrind et il vous donnera des informations sur les sources de données non initialisée. Il s'exécute plus lentement, mais peut être utile.Source: Valgrind Manuel De L'Utilisateur
OriginalL'auteur rocarvaj
Si Valgrind indique qu'une valeur n'est pas initialisé, puis dans 99.5% c'est vraiment pas initialisé. Normalement, lorsque le compilateur signale l'utilisation d'une valeur non initialisée (-Wuninitialized dans GCC), vous vérifiez en ligne se déroule, que votre non initialisée valeur peut être déclaré (et non initialisées) par exemple 10 niveaux de fonction inline "appels" (ou modèle déroule) de plus, que le réel GCC rapport. Valgrind fait la même chose, mais dans l'exécution. Donc, vous devriez vérifier tout le chemin dans lequel non initialisée valeur voyagé de la place de l'être déclaré (et non initialisé), à l'endroit où il est réellement utilisé. Le chemin d'accès peut être par exemple: la cascade d'appels de fonction, où chaque fonction passe ses arguments (et éventuellement non initialisée valeur) à la prochaine fonction. Valgrind fera rapport à la dernière fonction, lorsque la valeur est en fait utilisé.
En général, vous ne devriez pas ignorer ce que Valgrind unis. Valgrind est pas un simple programme de trace. Il peut être vu comme une machine virtuelle:
OriginalL'auteur
Il serait très utile si vous pouvez poster plus de code, en particulier à partir de la partie où valgrind pense que l'erreur est.
Si cela se produit chaque fois que vous instancier la classe, vous avez probablement oublié d'initialiser l'un des membres dans le constructeur.
Et oui: vous devriez Vous inquiéter à propos de cette erreur, ces gars-là peuvent vraiment vous mordre.
OriginalL'auteur bayer
En 64 bits machine.
Généralement, int prend 4 octets en mémoire. Mais de temps va durer 8 octets en mémoire. Donc, simplement renvoyer un int valeur tant le format de totalement résultat incorrect.
Une conversion est nécessaire dans cette situation.
OriginalL'auteur wuxianyun
L'erreur ne semble pas venir à partir de votre code, mais une bibliothèque que vous utilisez.
Valgrind est livré avec certains d'erreur par défaut de suppression, mais que, probablement, ne couvre pas la bibliothèque que vous utilisez.
Vous pouvez créer votre propre erreur suppressions que vous savez qu'ils sont sans rapport avec votre code.
Voir le semblable question Pourquoi ne Valgrind aime pas mon utilisation de glutCreateWindow?
OriginalL'auteur lothar