Mode debug différent de mode release - sprintf pas effectué à temps

Version imprimable

Bonjour tout le monde,

J'ai encore une bizarrerie :
- Lorsque j'exécute un code en mode release, il n'y a pas de problème.
- Lorsque j'exécute le même code en mode debug en ne mettant pas trop de points d'arrêts, il n'y a pas de problème.
- Lorsque j'exécute le même code en mode debug en ne mettant des points d'arrêts juste avant le sprintf() et juste après et encore juste après, il y a un problème.
Le problème est soit que le sprintf n'est pas effectué, soit que l'ordi tourne à fond, soit qu'il plante.

J'ai trouvé une solution. J'ai décomposé ma fonction en 3 fonctions et cela ne me paraît plus poser plus de problèmes. Mais j'ai voulu comprendre. J'ai alors dupliqué la fonction qui posait problème et j'ai enlevé tout ce qui ne posait pas de problème. Il reste le code suivant. Si on met des points d'arrêts partout, le programme a beaucoup de mal à passer d'un point d'arrêt à l'autre.

Il suffit de changer long long int en int, ou supprimer n'importe quelle ligne de code ou remplacer les variables par leurs valeurs pour que ça fonctionne.
Il met une trentaine de secondes à chaque étape et surtout, lorsqu'il s'est enfin arrêté au point d'arrêt après le sprintf, il n'a pas exécuté l'instruction ; il faut encore attendre pour que l'instruction soit prise en compte (alors qu'il est déjà arrêté au point d'arrêt).
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 void test(const char* string1) { long long int k,s,cnt,beg,end,op,s1,s1E; char* ptr; char* string2 = new char[100]; sprintf(string2,"diff(%s)",string1); k = 0; s = 0; cnt = 0; beg = 5; end = 0; op = 0; s1 = 13; s1E = 11; ptr = NULL; char op1 [s1 ]; memcpy(op1 ,&string2[beg] ,s1 -1); char op1E[s1E]; memcpy(op1E,&op1[s1 != s1E],s1E-1); } int main(int argc, char *argv[]) { test("12345678*123456"); return 1; }
Quelqu'un a-t-il déjà connu ce genre de problème svp ?

Merci à tous qui lisez mes messages et qui y répondez, sachant que je suis le seul à poser des questions...

Bonjour,

Pourquoi n'utilisez vous pas la gestion automatique de la mémoire (intérêt de faire du C++)

En C++ on pourrait avoir un code ressemblant à,

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#include <iostream>
#include <string>
#include <vector>
#include <cstring>  // Pour memcpy
 
void test(const std::string& string1)
{
    long long int beg, s1, s1E;
    std::string string2 = "diff(" + string1 + ")";
 
    beg = 5;
    s1  = 13;
    s1E = 11;
 
    std::string op1 = string2.substr(beg, s1 - 1);
    std::vector<char> op1E(s1E);
    memcpy(op1E.data(), &op1[s1 != s1E], s1E - 1);
    op1E[s1E - 1] = '\0';  // Ajout d'un null-terminator pour éviter les problèmes d'affichage.
 
    std::cout << "op1: " << op1 << std::endl;
    std::cout << "op1E: " << op1E.data() << std::endl;
}
 
int main()
{
    test("12345678*123456");
    return 0;
}

avec un résultat (ce qui ne semble pas être le cas chez vous)

Code:

1
2
3
fred1599@PC-Fred ~ $ ./my_program
op1: 12345678*123
op1E: 2345678*12

On pourrait ensuite avantageusement transformer en :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#include <iostream>
#include <string>
 
void test(const std::string& string1)
{
    long long int beg = 5, s1 = 13, s1E = 11;
    std::string string2 = "diff(" + string1 + ")";
 
    // Utilisation de substr pour éviter memcpy
    std::string op1 = string2.substr(beg, s1 - 1);
    std::string op1E = op1.substr(s1 != s1E ? 1 : 0, s1E - 1);
 
    std::cout << "op1: " << op1 << std::endl;
    std::cout << "op1E: " << op1E << std::endl;
}
 
int main()
{
    test("12345678*123456");
    return 0;
 
}

18/09/2024, 23h51
bacelar

Je plussois la réponse de @fred1599.

Citation:

Le problème est soit que le sprintf n'est pas effectué, soit que l'ordi tourne à fond, soit qu'il plante.

Vous utilisez quoi comme débogueur ?
Généralement, c'est pas le débogueur le problème. :aie:
En mode DEBUG, généralement, il n'y a pas d'optimisation, rendant le code "plus" stable qu'il ne le serait en mode RELEASE.
Mais il y a des réglages par défaut en DEBUG qui permettent de systématiquement détecter des conneries de développement.
DEBUG est donc aussi plus "stable" dans les "plantages" (éviter les "heisenbugs")

Mais tout ceci, c'est si vous utilisez une chaine de compilation et un débogueur "moderne".

Votre code est blindé de "conneries" (des choses à ne pas faire) en C++. C'est quoi votre niveau de Warning ? Avez-vous bien tenu compte des warning du compilateur et de l'éditeur de lien ?

Citation:

Il suffit de changer long long int en int, ou supprimer n'importe quelle ligne de code ou remplacer les variables par leurs valeurs pour que ça fonctionne.

Cela déclenche mon biais à faire des corrélations abusives mais je sens que l'utilisation des VLA dans votre code, qui n'ont jamais été supportés en C++ et que brièvement en C, n'est pas étrangère à vos problèmes.
Lisez et comprenez les warning (et activez leur niveau maximum).

Citation:

Il met une trentaine de secondes à chaque étape et surtout, lorsqu'il s'est enfin arrêté au point d'arrêt après le sprintf, il n'a pas exécuté l'instruction ; il faut encore attendre pour que l'instruction soit prise en compte (alors qu'il est déjà arrêté au point d'arrêt).

Un classique de ce genre de truc, c'est que les variables soient "correctement" initialisées avec du "FBADBEEF" qui entraine une grande taille d'allocation => temps énorme pour que l'OS trouve la place nécessaire, puis le débogueur qui perd ses petits parce que cela prend trop de temps, que des éléments de validations DEBUG soient énormes ou écrasées. Et un débogueur n'est jamais un outil "temps réel", surtout si on lui file un code foireux (non standard) dans les pattes.

Des librairies de manipulations, mise en forme, etc... de chaines de caractères, en C++, il y en a par dizaines, si ce que fourni le standard C++ ne suffirait pas.

Citation:

Quelqu'un a-t-il déjà connu ce genre de problème svp ?

Oui, et les warning m'ont ouvert les yeux.:mrgreen:

Bonjour et merci pour vos réponses.

Je ne sais pas ce que j'utilise comme débogueur ; je travaille sous Qt Creator. Je ne sais pas comment faire pour toucher le makefile. J'appuie sur F5 pour lancer le débogueur. Les processus suivants tournent :

Code:

1
2
3
4
Nom de l'image		Processeur	Mémoire
gdb.exe *32		00 %		488 K
gdborig.exe *32		48 %		112 368 K
qtcreator.exe *32	01 %		128 276 K

Mon code est blindé de conneries ? Là, il est correct ?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
void test(const char* string1)
{
  long long int  k,s,cnt,beg,end,op,s1,s1E;
  char*          ptr;
  char*          string2 = new char[100];
 
  if (sprintf(string2,"diff(%s)",string1) != -1)
  {
    k   = 0LL;
    s   = 0LL;
    cnt = 0LL;
    beg = 5LL;
    end = 0LL;
    op  = 0LL;
    s1  = 13LL;
    s1E = 11LL;
    ptr = NULL;
    char op1 [s1 ]; memcpy(op1 ,&string2[beg]  ,s1 -1);
    char op1E[s1E]; memcpy(op1E,&op1[s1 != s1E],s1E-1);
  }
  delete [] string2;
}
 
int main(int argc, char *argv[])
{
  test("12345678*123456");
  return 0;
}

Je ne sais pas c'est quoi mon niveau de warning, les warning sont indiqués ci-dessous.
Comment activer le niveau maximum de warning svp ?
Pour les VLA, c'est très mal vu, mais puisque c'est possible, c'est qu'on doit pouvoir les utiliser.

Je n'ai pas trouvé sur internet ce que FBADBEEF est.
Je n'ai pas trop compris ce paragraphe, surtout la phrase << puis le débogueur qui perd ses petits parce que cela prend trop de temps, que des éléments de validations DEBUG soient énormes ou écrasées >>.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
12:53:45: Exécution des étapes pour le projet Test...
12:53:45: Configuration inchangée, étape qmake sautée.
12:53:45: Débute : "C:\Qt\Qt5.4.1\Tools\mingw491_32\bin\mingw32-make.exe" 
C:/Qt/Qt5.4.1/Tools/mingw491_32/bin/mingw32-make -f Makefile.Debug
mingw32-make[1]: Entering directory 'E:/Nouveau/Science/build-Test-Desktop_Qt_5_4_1_MinGW_32bit-Debug'
g++ -c -pipe -fno-keep-inline-dllexport -std=c++11 -g -frtti -Wall -Wextra -fexceptions -mthreads -DUNICODE -DQT_CORE_LIB -I"..\Z0\Test" -I"." -I"C:\Qt\Qt5.4.1\5.4\mingw491_32\include" -I"C:\Qt\Qt5.4.1\5.4\mingw491_32\include\QtCore" -I"debug" -I"C:\Qt\Qt5.4.1\5.4\mingw491_32\mkspecs\win32-g++"  -o debug\misc.o ..\Z0\Graph\misc.cpp
g++ -c -pipe -fno-keep-inline-dllexport -std=c++11 -g -frtti -Wall -Wextra -fexceptions -mthreads -DUNICODE -DQT_CORE_LIB -I"..\Z0\Test" -I"." -I"C:\Qt\Qt5.4.1\5.4\mingw491_32\include" -I"C:\Qt\Qt5.4.1\5.4\mingw491_32\include\QtCore" -I"debug" -I"C:\Qt\Qt5.4.1\5.4\mingw491_32\mkspecs\win32-g++"  -o debug\draw.o ..\Z0\Graph\draw.cpp
g++ -c -pipe -fno-keep-inline-dllexport -std=c++11 -g -frtti -Wall -Wextra -fexceptions -mthreads -DUNICODE -DQT_CORE_LIB -I"..\Z0\Test" -I"." -I"C:\Qt\Qt5.4.1\5.4\mingw491_32\include" -I"C:\Qt\Qt5.4.1\5.4\mingw491_32\include\QtCore" -I"debug" -I"C:\Qt\Qt5.4.1\5.4\mingw491_32\mkspecs\win32-g++"  -o debug\graph.o ..\Z0\Graph\graph.cpp
g++ -c -pipe -fno-keep-inline-dllexport -std=c++11 -g -frtti -Wall -Wextra -fexceptions -mthreads -DUNICODE -DQT_CORE_LIB -I"..\Z0\Test" -I"." -I"C:\Qt\Qt5.4.1\5.4\mingw491_32\include" -I"C:\Qt\Qt5.4.1\5.4\mingw491_32\include\QtCore" -I"debug" -I"C:\Qt\Qt5.4.1\5.4\mingw491_32\mkspecs\win32-g++"  -o debug\string.o ..\Z0\Graph\string.cpp
g++ -c -pipe -fno-keep-inline-dllexport -std=c++11 -g -frtti -Wall -Wextra -fexceptions -mthreads -DUNICODE -DQT_CORE_LIB -I"..\Z0\Test" -I"." -I"C:\Qt\Qt5.4.1\5.4\mingw491_32\include" -I"C:\Qt\Qt5.4.1\5.4\mingw491_32\include\QtCore" -I"debug" -I"C:\Qt\Qt5.4.1\5.4\mingw491_32\mkspecs\win32-g++"  -o debug\main.o ..\Z0\Test\main.cpp
..\Z0\Test\main.cpp: In function 'void test(const char*)':
..\Z0\Test\main.cpp:14:18: warning: variable 'k' set but not used [-Wunused-but-set-variable]
   long long int  k,s,cnt,beg,end,op,s1,s1E;
                  ^
..\Z0\Test\main.cpp:14:20: warning: variable 's' set but not used [-Wunused-but-set-variable]
   long long int  k,s,cnt,beg,end,op,s1,s1E;
                    ^
..\Z0\Test\main.cpp:14:22: warning: variable 'cnt' set but not used [-Wunused-but-set-variable]
   long long int  k,s,cnt,beg,end,op,s1,s1E;
                      ^
..\Z0\Test\main.cpp:14:30: warning: variable 'end' set but not used [-Wunused-but-set-variable]
   long long int  k,s,cnt,beg,end,op,s1,s1E;
                              ^
..\Z0\Test\main.cpp:14:34: warning: variable 'op' set but not used [-Wunused-but-set-variable]
   long long int  k,s,cnt,beg,end,op,s1,s1E;
                                  ^
..\Z0\Test\main.cpp:15:18: warning: variable 'ptr' set but not used [-Wunused-but-set-variable]
   char*          ptr;
                  ^
g++ -Wl,-subsystem,console -mthreads -o debug\Test.exe debug/misc.o debug/draw.o debug/graph.o debug/string.o debug/main.o  -LC:/Qt/Qt5.4.1/5.4/mingw491_32/lib -lQt5Cored 
mingw32-make[1]: Leaving directory 'E:/Nouveau/Science/build-Test-Desktop_Qt_5_4_1_MinGW_32bit-Debug'
12:53:57: Le processus "C:\Qt\Qt5.4.1\Tools\mingw491_32\bin\mingw32-make.exe" s'est terminé normalement.
12:53:57: Temps écoulé : 00:12.

19/09/2024, 15h20
deedolith

Salut,

Premier point, ton code n'est pas du C++.

Ensuite, qu'entends-tu par "il y a un problème" ?

Garde bien en tête qu'en mode debug, l'exécutable est généré avec les informations de debug, pour permettre l'observation des variables, l'execution en pas à pas, les points d'arrêt ect ..., il suffit de comparer la taille des éxécutables générés pour s'en rendre compte.
L'environnement d'exécution est également complètement diffèrent.

Donc il est possible qu'une anomalie subordonnée au mode Debug soit un faux positif.

Le mieux est encore de faire tourner des tests unitaires.
19/09/2024, 15h59
Nauvisse
Bonjour et merci.

J'avais mal tapé le message initial, je l'ai corrigé. De plus, j'avais tapé

Citation:

Le problème est soit que le sprintf n'est pas effectué, soit que l'ordi tourne à fond, soit qu'il plante.

, mais il est possible que le plantage soit dû à une autre erreur.

Donc, le problème est que, si je mets des points d'arrêts en début de chaque ligne :
- On passe du point d'arrêt juste avant le sprintf au point d'arrêt juste après le sprintf au bout de 20 secondes.
- L'affichage de string2 a lieu encore 30 secondes après l'exécution du sprintf.
- De même, l'affichage des variables a lieu 30 secondes après l'exécution de chaque instruction suivante. (Et si je veux passer au point d'arrêt suivant sans attendre l'affichage, il mettra alors 30 secondes avant d'effectuer l'instruction).

Citation:

Premier point, ton code n'est pas du C++.

J'ai posté mon message ici car lorsque je poste sur le forum C, on me dit qu'il faut poster le message sur le forum C++.

Citation:

Donc il est possible qu'une anomalie subordonnée au mode Debug soit un faux positif.

Oui, c'est ce que je vais me dire.
Et je prends en compte

Citation:

l'utilisation des VLA dans votre code, qui n'ont jamais été supportés en C++ et que brièvement en C, n'est pas étrangère à vos problèmes

.

Merci aussi de me conseiller d'utiliser
Code:

1 2 #include <string> #include <vector>
, il faudra que je m'y mette.

Par exemple, si j'enlève la ligne

Code:

ptr = NULL;

, le programme plante et affiche 2 petites fenêtres :

Citation:

Le processus gdb s'est arrêté de façon inattendue (code 3).

Citation:

Windows recherche une solution au problème.
19/09/2024, 18h36
deedolith

Citation:

Envoyé par Nauvisse

Par exemple, si j'enlève la ligne

Code:

ptr = NULL;

, le programme plante et affiche 2 petites fenêtres :

Pointeur non initialisé, donc ... UB (Undefined Behavior, AKA Comportement indéterminé).

PS: En C++, on préfère initialiser les pointeurs nu avec la valeur NullPtr, qui d'une part est plus clair à lire, et d'autre part n'est pas égale à zéro, contrairement à la valeur NULL.
Voir on préfère ne pas utiliser les pointeurs nu tout court. La librairie standard fournit les pointeurs intelligents (std::unique_prtr, std::shared_ptr) pour répondre aux nombreux problèmes que posent les pointeurs nu.
19/09/2024, 18h47
kaitlyn

Salut,

Lenteur et instabilité, peut-être un antivirus qui interfère.
19/09/2024, 21h51
Nauvisse

Bonjour et merci,

Je n'utilise pas ptr dans le programme, donc ne pas l'initialiser ne devrait pas poser de problème.

J'ai désactiver l'antivirus et j'ai le même résultat.
20/09/2024, 06h45
kaitlyn

Salut,

J'ai vérifié le code de ton premier message sur le débogueur d'onlineGDB (https://www.onlinegdb.com/online_c++_compiler) et il n'y a rien eu de particulier. Une réinitialisation ou une mise-à-jour de tes outils réglera peut-être ton problème. Avoir un deuxième compilateur sous le coude ça aide aussi parfois.
20/09/2024, 10h57
Nauvisse

Bonjour et merci

Je me doutais qu'il y avait quelque chose comme ça parce que c'était les variables du code précédent dont le débogueur se souvenait. Il fallait vraiment que ce soit les mêmes variables.

Comment faire une réinitialisation ou une mise-à-jour svp ?

Je travaille sous Qt Creator 5.4.1.
20/09/2024, 12h59
kaitlyn

N'utilisant pas qt, je ne saurai dire. À défaut d'une réponse, tu trouveras l'information dans le forum du même nom.
À noter aussi que tu utilises une version 32bits, si c'est voulu.
20/09/2024, 13h28
Nauvisse

Merci

Non, ce n'est pas voulu, mais je ne sais pas comment faire.

Les versions de Qt ont l'air payantes (10.000 euros par an en location), je ne sais pas où trouver des versions gratuites ou au tarif normal.
20/09/2024, 14h08
kaitlyn

Ceci peut-être : https://www.qt.io/download-qt-installer-oss
20/09/2024, 16h12
Nauvisse

Merci beaucoup
27/09/2024, 09h45
Luc Hermitte

Les symptômes décrits sont typiques d'UB et de variables non initialisées.

Pour autant le codé précis partagé n'a pas l'air d'en avoir (si l'on excepte les VLA -- extension supportée par gcc & clang et qui peut faire exploser la pile et donc les programmes) si j'écoute le sanitiser (enfin... il y a une fuite). Et il y a clairement un risque de débordement à utiliser sprintf au lieu de snprintf/sprintf_s...

Mais des warnings à foison de variables non utilisées (typique quand on déclare tout en début de programme -- c'est une mauvaise pratique, cf FAQ), et sonar Qube en voit encore d'autres: https://godbolt.org/z/bvn74WdP9 (qui rejoignent ce que mes VDD ont dit: c'est pas comme ça que l'on écrirait du C++)

Le code qui présentait les comportements erratiques était vraiment celui-ci, ou il s'agit d'un autre code?
27/09/2024, 13h46
Nauvisse

Bonjour et merci pour votre réponse.

Je ne connais pas trop votre vocabulaire (UB, sanitiser, VDD).

Le code qui présentait un comportement très lent en mode debug était à l'origine une fonction plus longue. J'ai recopié la fonction dans une autre application Qt Creator et j'ai supprimé toutes les instructions et déclarations qui faisaient disparaître le bug. Il est resté les variables déclarées et les VLA. Effectivement, en mode debug, je voyais

Code:

char op1[~4,6 millions]

.

Savez-vous comment détecter les fuites mémoire avec Qt Creator sous windows. Je dispose bien de Valgrind, mais je ne sais pas comment l'utiliser et j'ai lu que ça ne fonctionnait pas sous Windows ?

Merci d'avance.
27/09/2024, 18h46
Luc Hermitte

VDD: voisin du dessus

UB: Undefined behaviour. Il y en aurait des heures pour présenter la chose correctement, sans parler d'extensivement. En résumé, le compilateur n'a qu'une seule obligation: produire un binaire dont le résultat observable de l'exécution est conforme à un code correct qui a été écrit. C'est grossièrement la règle du "as-if". Le corollaire est que si un code n'est pas correct, il fait ce qu'il veut. Et il suffit de changer une ligne, définir une fonction avant ou après, et le comportement observé change de manière erratique et non prévisible.
Et donc quand le comportement est bizarre en C ou en C++, c'est qu'il y a UB. Ou sous-cas particuliers de variable non initialisée, data-race en situation multithreadée...

Le VLA avait une taille à la noix: bon signe de UB donc. la taille devait ne pas etre initialisée ou venir d'un chemin qui n'a pas de sens. Déjà retarder au maximum où les variables sont déclarées et de préférence les déclarer const. Ca limitera une part non négligeable de ce genre de soucis. Cf la FAQ C++ d'ici. (ou n'importe quel bon référentiel qualité pour le C++)

Compiler aussi avec les warnings à fond: "-Wall -Wextra" (en version simple) pour g++ et clang (pas me demander où cela se configure dans QtCreator).

Les sanitiseurs, c'est valgrind en mieux -- à quelques détails près. Sous windows... il parait que c'est intégré à Visual Studio via clang aujourd'hui. Et vivant sous Linux, je ne vais vraiment pas pouvoir aider plus sur ce sujet.

Dernier truc: le code. Il faut le moderniser et virer cet héritage C. M'est avis que cela aurait limité quantité de soucis observés.
28/09/2024, 01h23
Nauvisse

Merci beaucoup.