Discussion :

[koukou11]

slt, je travaille sous vc++ , mon code s'exécute normalement mais quand je viens de fermer la boite de dialogue, je trouve l'erreur suivante(boite de message):

HEAP CORRUPTION DETECTED: after block #119 at 0x001063C8
CRT detected that the application wrote to memory after end of heap buffer

est ce cela peut être du aux pointeurs?( j'utilise l'allocation dynamique )
j'ai vérifié la taille des tableaux et je ne trouve pas qu'ils sont inférieures à la taille des données contenues.

Quelqu'un peut m'aider s'il vous plait?

[r0d]

Bonjour,

cette erreur signifie que quelque part tu écris en dehors de la mémoire que tu as alloué. Du coup le tas est corrompu et lorsqu'il essaie de tout désallouer, ça crashe.

Il y a milles façons de créer une "heap corruption", mais bien évidemment, une mauvaise manipulation de pointeurs est bien souvent la cause. C'est une des raisons pour lesquelles on dit: "utiliser les pointeurs que quand on ne peut pas faire autrement".

[bacelar]

Pour être précis, vous avez ce message car vous êtes en mode DEBUG et, avec les bonnes options de compilation, à chaque fois que vous faite une allocation dans le tas, le C-Runtime en DEBUG ajoute quelques octets avant et après la zone mémoire qui est fourni au programme.
Par exemple, après un appel à la fonction malloc de X octets qui retour un pointeur P, alors, dans la mémoire du processus, il y a quelques octets aux adresses juste inférieurs à P avec des valeurs spéciales, type 0xCC, et il y a quelques octets aux adresse juste supérieurs à P+X qui contiennent aussi des valeurs spéciales.

Au moment d'une libération de mémoire, la C-Runtime vérifie pour tous les bloques de mémoires qu'elle a allouée (et pas uniquement celle qu'elle est en train de désallouer), que ces 2 zones contiennent toujours ces valeurs spéciales.
Si ce n'est plus le cas, la C-Runtime ouvre cette fameuse fenêtre d'alerte.

Attention, cette vérification à la libération de mémoire n'est pas systématique à moins de le spécifier avec _CrtSetDbgFlag (entre autre).
http://msdn.microsoft.com/en-us/libr...(v=vs.71).aspx

Moi, sur ce genre de problème, j'active le check systématique de la mémoire pour prendre le code fautif la main dans le sac.

[koukou11]

slt, merci pour la réponse. Cela m'a clarifié les choses
pour la fonction _CrtSetDbgFlag , elle est utilisée en C alors que je travaille avec VC++ ( opérateur new et delete pour les pointeurs).

pour le check systématique de la mémoire, comment l'activer? Merci

[bacelar]

Les primitives new et delete utilisent les primitives malloc et free.

Donc CrtSetDbgFlag marche aussi pour les allocations C++ "standard".

pour le check systématique de la mémoire, comment l'activer? Merci

C'est pratiquement dans l'exemple de la page MSDN que je vous ai fourni.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
// Get the current state of the flag
// and store it in a temporary variable
int tmpFlag = _CrtSetDbgFlag( _CRTDBG_REPORT_FLAG );
 
// Turn On (OR) - launch _CrtCheckMemory from
// being called at every allocation request
tmpFlag |= _CRTDBG_CHECK_ALWAYS_DF;
 
// Set the new state for the flag
_CrtSetDbgFlag( tmpFlag );

[koukou11]

si je mets ce code dans chaque fichier .cpp , est cela est suffisant ?ou bien après chaque allocation et désallocation de mémoire? Merci

[bacelar]

si je mets ce code dans chaque fichier .cpp , est cela est suffisant ?ou bien après chaque allocation et désallocation de mémoire? Merci

Houlà, vous êtes un peu jeune dans le C/C++ semble-t-il.

Avec cette fonction de la C-Runtime, vous modifiez le comportement de la C-Runtime, donc de tous le code qui se sert de la C-Runtime et cela dés l'appel de cette fonction.

Vous n'avez qu'à APPELLER cette fonction UNE seule fois.
Au début de la fonction main par exemple, si vous voulez vérifier dés le départ que votre heap (tas) mémoire n'est pas corrompu.

Les variables globales seront déjà allouée au moment du début de la fonction main, donc de l'appel de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

_CrtSetDbgFlag( tmpFlag );

, donc vous ne pourrez pas vérifier quelle constructeur d'une variable globale fout le Bronx dans le tas, mais les variables globales, c'est mal.

[koukou11]

J'ai une application MFC, donc je n'ai pas de main() . j'ai mis le code au niveau de chaque constructeur avant l'allocation de mémoire ??

[bacelar]

Vous n'avez pas de "main" mais un équivalent : la méthode "InitInstance" de la classe dérivant de "CWinApp".

j'ai mis le code au niveau de chaque constructeur avant l'allocation de mémoire ??

Arrêtez de jouer au galérien.

[koukou11]

OK MERCI et pour les classes qui n'ont pas de initInstance() (qui héritent de CDialog)?

[koukou11]

je crois que je l'ai trouvé ca correspond à la fonction OnInitDialog() pour les fichiers crées par défaut mais pour les classes que j'ai ajouté et qui héritent de CDialog, cette fonction n'existe pas , aussi pour les classes qui héritent de CWnd.

[bacelar]

Vous n'avez qu'à APPELLER cette fonction UNE seule fois.

J'ai bien dit une fois (par programme) et non par classe.

Vous n'avez qu'à modifier que la méthode "InitInstance" de la classe dérivant de CWinApp, ET PUIS C'EST TOUT.