Bonjour,
 
Je suis en train de migrer une application ecrite en C 32bits pour l'optimiser en mode "terminal server" sous Windows 2003.
 
Je viens de remarquer un plantage qui n'est present que en OS Windows 2003:
 
je parcour un tableau et pour chaque element je fais:
GlobalFreePtr(tab_arg[nI]);
 
Depuis mon portage en environnement TS, parfois (car ca ne le fais pas systematiquement)
L'application plante sur la desallocation (erreur memoire windows)
Pour résoudre mon problème j'ai mis ca et ca marche:
tab_arg[nI] = NULL;
GlobalFreePtr(tab_arg[nI]);
 
   
 
Ma question: Je vais surement devoir mettre une affectation à null avant chaque GlobalFreePtr. Est -il possible de "surcharger" ma fonction pour ne pas devoir me taper tout les GlobalFreePtr du code? Pour ne pas mourir idiot, quelqu'un peut m'expliquer pourquoi parfois GlobalFreePtr plante et si c'est normal de faire une affectation a null pour résoudre ce problème?    
 
Merci  

Habituellement, un plantage sur une libération de ressource survient lorque la ressource n'a pas été alloué. Je pense donc qu'il vaudrait mieux intialiser au début tous les éléments de la table tab_arg[nI] à NULL, et de tester avant de faire le GlobalFreePtr si l'élément est NULL ou non.

Merci olivthill
 
en faite l'application est de tres tres grande envergure (+1000fichiers source) et elle tourne depuis presque 20ans!!! je ne connais juste qu'un peu son architecture. je fais principalement du debogage pour me déplacer dans ces infinités de source...  
 
j'ai oublidé de préciser que il ya bien un test avant
if (tab_arg[nI])
  GlobalFreePtr(tab_arg[nI]);
 
que j'ai modifié en :
if (tab_arg[nI]) {
  tab_arg[nI] = NULL;
  GlobalFreePtr(tab_arg[nI]);
}
 
en debugage, ca plante sur certaine valeur de tab_arg[nI] qui ne sont pas nul, mais rempli par des caractères binaires....
 
pourtant le tableau est bien initialisé en debut de prog:
LPSTR tab_arg[NB_CHAMP_PRIMITIVE_ANTER]  
for (nI=0;nI>NBCHP_PRIMITIVE_ANTER;nI++)  
  tab_arg[nI]=NULL;
 
par contre ce qui m'interpele, c'est que ce GlobalFreePtr n'a jamais posé de probleme sur les OS 3.1,95,98,2000,XP.
Seulement depuis qu'on la migre en 2003 (pour utiliser au mieu le TS)....

arf
 
il doit donc avoir un tab_arg[nI] = GlobalAllocPtr(GPTR,nLg) qui ne se passe pas au mieu....
 
 
ca promet encore du degogage tout ca  

est équivalent à GlobalFreePtr(NULL);. Ca ne fait rien, ça ne libère rien du tout. Ce serait plus sérieux de débgguer.

exacte. Bon je vais debogé

bon
je crois que j'ai trouvé
le code de libération c'est ca:
 
 
  if (lpstr_pat)
    GlobalFreePtr(lpstr_pat);
  if (lpszDanais1)
    GlobalFreePtr(lpszDanais1);
  if (lpszDanais2)
    GlobalFreePtr(lpszDanais2);
  for ( nI=0 ; nI<NBCHP_PRIMITIVE_ANTER ; nI++ )  
    {
      if (tab_arg[nI]) {
 GlobalFreePtr(tab_arg[nI]);
 
 
Or!!!! tab_arg[5] est affecté avec lpszDanais2, qui elle meme est liberé juste avant!! donc GlobalFreePtr plante quand il est excecuté sur une variable qui viens d'etre liberé (car oui tab_arg[5] n'est pas null)
 
bon bon, je vais me faire un petit test du bout de code sous 2000, car ca m'interpelle que ce plantage ne soit visible que sous 2003

C'est pas parce que tu n'as jamais vu le code planter sur ce morceau de code qu'il ne plantera jamais sur ce meme morceau. Liberer une zone deja liberee, ca fait des choses indeterminees qui dependent de ce qui s'est passe entre les deux deallocations, de l'allocateur utilise par la libc...