Discussion :

[Denn's]

Salut,

Quand je teste mon appli ( construite dans sa version finale ), j'ai des soucis au niveau allocation/libération de mémoire.

Quand elle plante ( Je suis en Release/static Library ) et que je fais annuler pour déboguer ( J'ai fais générer debug info dans les settings du projet ),
le débogueur m'indique que l'erreur a lieu dans le contexte suivant:
" MONAPPLI.EXE! __sbh_free_block " avec les lignes assembleur qui vont bien.....

J'ai recherché à quoi correspondait ce __sbh_free_block dans la MSDN mais j'ai rien trouvé.

Quelqu'un-a-t-il déjà eu ce problème ?

[kacedda]

Et ca plante pas en debug? en faisant les memes actions?

[Denn's]

ouaip!

[kacedda]

Je suis pas sur mais il me semble que tu peux linker la release avec les sources(faire une sorte de semi-release) a partir des settings, ca pourra peut-etre deja t'aider, histoire d'avoir la call-stack si ca plante.

Et sinon ben si ca le fait toujours au meme moment/endroit, ben faut essayer de trouver la fenetre/dialog/classe sur laquelle ca plante, mais bon la je t'apprend rien...

Aussi il me semble que le compilo initialise les variables en mode debug mais pas en release, du coup petre que t'essaye de liberer du nimp.

[stephdim]

salut

la fonction "__sbh_free_block" est une fonction de la librairie CRT qui est appellée par free() ou delete.

a mon avis, tu essayes de libérer un bloc déjà libéré (par free() ou delete) ou pire, tu as corrompu le heap en faisait un dépassement de buffer par ex (buffer overrun) -> tu écris là ou il faut pas

reverifies tout tes appels à malloc / new et free / delete.

@+

[Denn's]

Salut,

J'ai peur que ce soit la deuxième solution ( juste avant d'avoir les fenêtres de débogage ), j'ai le message "Access Violation", et encore avant, le message "l'instruction à l'adresse 0xXXXXXXX tente d'écrire à l'adresse 0xZZZZZ;la mémoire ne peut pas être Written".

Comment le heap peut-être corrompu ?
Normalement, l'allocation est bien globale,pas locale, non ?
Je fais juste des new / delete , pas des malloc/free et dans mon fichier *.cpp, je n'inclus comme entête que le <afxwin.h>, pas même le moindre petit <iostream/iostream.h>.

Si c'est vraiment le heap qui est corrompu, comment je puis éviter çà ?

[Médinoc]

Un débordement de buffer est une des principales sources de corruption du tas.

[farscape]

salut,
le fait d'utiliser new et delete n'empêche pas le fait que tu puisses faire des débordements mémoire...
pour les recommandations voir ce post:
http://www.developpez.net/forums/sho...32#post2764032
le post ci-dessous de la faq donne aussi quelques informations sur l'initialisation des pointeurs.
suivant ce que tu obtiens ça donne une piste sur le problème.
http://cpp.developpez.com/faq/vc/ind...gPointeurValue

[Denn's]

Salut,

Au début du post, je disais que ça plantait dans mon programme et que le contexte était MONAPP.EXE __sbh_free_block. ( Static Library )
Ca plante aussi parfois dans le context suivant : NTDLL.DLL. ( Shared DLL )

La je pense pas que ça vienne de mes allocation/libération.
Est-ce que ça peut venir d'une mauvaise gestion des CView et CDialog ?
( style: pas assez de fonction par défaut redéfinies etc . )

A+.

[Denn's]

Salut,

Est-ce qu'il y a moyen de corriger ces problèmes avec un service Pack ?
Si oui lequel?
Et si c'est le quatrième, est-ce qu'il faut avoir installé le premier,le deuxième et le troisième avant ?

Merci d'avance.