2017-02-11 1 views
-1

Pouvons-nous faire une liste des causes qui font que le programme s'exécute correctement lorsqu'il est compilé en mode débogage, mais pour planter en mode release, avec Qt Creator. Parlons en général, dans la plupart des cas.En général, avec Qt Creator, qu'est-ce qui peut provoquer un programme à s'exécuter correctement lorsqu'il est compilé en mode débogage, mais se bloquer en mode release?

Dans mon cas, au point A, le programme compilé et exécuté correctement. Après un travail, au point B, il compile mais plante à l'exécution en mode release et non en mode debug, je retourne au point A en commentant mon travail entre A et B, il a le même comportement que le point B, il se compile mais se bloque seulement en mode de libération. Je pense que c'est une erreur que j'ai faite beaucoup avant le point A qui dormait. Cela ne me donne pas envie de finir mon programme, puisque c'est un programme gratuit que je voulais partager en open source.

+7

Un comportement indéfini est une cause probable. Faites attention à tous les avertissements du compilateur. Si vous n'avez pas reçu d'avertissement, augmentez le niveau d'avertissement de votre compilateur et voyez s'il y en a après l'augmentation. – drescherjm

+1

Avez-vous des exemples de code? Les possibilités de réponse actuelles sont larges (pour moi, au moins). –

Répondre

1

Tout type de comportement indéfini peut provoquer ce type de problème. La cause la plus probable - écrire au-delà de la limite d'un tableau/vecteur, ou lire à partir de là. Cela peut être une destruction d'un objet déjà détruit. Ou un problème de multithreading qui ne se reproduit que lorsque l'exécution est rapide en mode release. Il peut s'agir d'une structure non initialisée ou d'un champ de type POD non affecté au constructeur. En mode de débogage, la mémoire est allouée différemment et dans certains cas, elle peut contenir des zéros (lorsqu'elle est transmise à votre programme) plutôt qu'une corbeille aléatoire. Cela provoque souvent des plantages uniquement en mode Release.

Je vous recommande fortement de configurer la configuration "RelWithDebInfo" pour déboguer ce problème, par ex. passer l'option -g à GCC lors de la construction dans Release. Ainsi, vous serez en mesure d'arrêter dans le débogueur lorsque l'application se bloque et d'identifier la cause. Sinon, le mieux est de faire quelque chose comme "recherche binaire" sur votre code pour trouver l'emplacement exact de l'accident. Comme, commenter la moitié du code, voir si elle se bloque toujours, etc

Je sais que cette explication est un peu vague, mais j'espère que ça aide!

+2

_ "Je sais que cette explication est un peu vague ..." _ Eh bien, que pouvait-on attendre d'une question trop vague et trop large? –

+0

"En mode débogage, la mémoire est allouée différemment et, dans certains cas, elle peut contenir des zéros (lorsqu'elle est transmise à votre programme) plutôt qu'une poubelle aléatoire." En fait, c'est généralement le contraire. le tas de débogage remplit les pages désallouées avec un motif fixe pour aider à repérer les bogues de mémoire non initialisés. –

+0

@MatteoItalia Je pense que vous pourriez aussi bien être correct en général, je dis juste de mon expérience. Y a-t-il des prooflinks? :) –