Salut,
J’ai un problème dans Visual C++ 6.0, à certains moments quand je fait un free sur un char* ça m’envoie à un breakpoint imaginaire dans : ma_fonction << free << NTDLL! … << … << NTDLL! 7847193c().
Est-ce que quelqu’un sait d’où ça peut venir ?
Merci.
:kimouss:
En mode debug je crois que c’est pour te montrer que y a un problème. Du genre une libération de mémoire qui existe pas…
Je sais pas si tu pourrais nous montrer le "free" qui lance ce breakpoint…
A un endroit du code j’ai une ligne du genre :
entity->STEP_FileName = g_strdup_printf("%s", filename);
où je suis sur qu’il y a quelquechose dans filename, car si filename est NULL ou = “” alors on ne passe pas dans la fonction.
Ensuite dans la fonction de destruction d’une entité j’ai un :
free(entity->STEP_FileName);
et c’est là que ça plante, de même ça ne passe pas dans le code si l’entité est NULL et quand je regarde ce qu’il y a dans entity->STEP_FileName, ce n’est pas NULL et le breakpoint “imaginaire” est appelé dans tous les cas.
J’ai d’ailleurs testé aussi en déclarant un autre char* que j’ai alloué à 10*sizeof(char) par exemple et ou j’ai mis “123456789\0”, en faisant un free ça fait pareil.
La fonction g_strdup_printf est une fonction de glib définie comme ça :
Il faut donc bien faire un free dessus après utilisation. Et je suis sur qu’il n’y a pas de free fait ailleurs dessus.
:kimouss:
Tu es sûr que tu n’as pas un gfree ou un truc équivalent?
Bah, le seul endroit où il y a un free lié à entity->STEP_FileName, c’est ici :
temp_str2 = g_strdup_printf(entity->STEP_FileName);
if (strchr(temp_str2, '/') != NULL)
{
sep = g_strdup_printf("/");
}
else
{
sep = g_strdup_printf("\\");
}
temp_str = strtok (temp_str2, sep);
while (temp_str != NULL)
{
poly_name = g_strdup_printf("HLT %s", temp_str);
temp_str = strtok (NULL, sep);
}
[...]
free(temp_str);
Mais bon temp_str utilise temp_str2 qui est récupéré à partir d’un g_strdup_printf donc normalement doit être réalloué et copié, ce qui donc ne devrait pas avoir d’influence sur le free(entity->STEP_FileName).
Sinon il y a un entity->STEP_FileName = NULL; lors de l’initialisation de entity mais qui prend une valeur correcte lors du
entity->STEP_FileName = g_strdup_printf("%s", filename);
:kimouss:
Edit : je viens de tester en commentant le "free(temp_str);" et ça fait toujours le breakpoint lors du "free(entity->STEP_FileName);".
T’es sûr que tu n’as pas posé simplement un breakpoint en cliquant sur une ligne quelconque de ton fichier?
Ouais je suis sûr, en faisant ctrl+b on affiche la liste et il n’y a rien, puis l’endroit où est le breakpoint c’est dans NTDLL! 7847193c(), donc une dll où je ne sais quoi, enfin ça affiche de l’assembleur, et je n’ai jamais ouvert ce fichier moi même, i ls’ouvre simplement quand il apelle ce breakpoint “imaginaire”.
Sinon j’ai testé sous Linux avec gdb et le breakpoint n’est pas appelé dans un équivalent de NTDLL où autre.
:kimouss:
Edit : je viens de tester, quand je clic sur le côté gauche d’une ligne ça n’ajoute pas de breakpoint automatiquement, puis bon je l’aurais vu le gros point rouge à gauche :D.
On sait jamais 
Je vois pas, j’utilise jEdit et c’est pas un IDE donc bon.
Bon bein merci quand même, du coup je commente la ligne lorsque je suis en mode debug et la décommente pour compiler l’appli normale.
:kimouss:
Il est possible que ton probleme vienne d’ailleur en fait. Les probleme memoire comme ca sont tres fourbe, car si la memoire est alloué en contigue, tu peux tres bien faire un debordement d’ecriture sur ton pointer (qui ne vas pas planter puisque ta memoire est justement contigue, donc elle t’appartient), qui va donc ecrasé la valeur dans se pointeur et quand tu vas appelé free, vu que la valeur est mauvaise, ca va planter.
Essaye de faire une printf (ou une boite de dialogue) avec le contenue de ta chaine de caractère, tu auras peut etre des surprises.
Sinon tu as des lib qui te permettent de detecter ce genre de probleme.
Ok, merci, mais dans le debug on voit la valeur de la chaine et c’est bien celle qu’il faut : chemin complet vers un fichier .stp ou .step et il y a bien toujours le chemin, le nom et l’extension, pas plus ni moins.
:kimouss: