Visual 6.0 : dbgheap.c && _heap_alloc_dbg && _CrtDbgBreak()

Visual 6.0 : dbgheap.c && _heap_alloc_dbg && _CrtDbgBreak() - C++ - Programmation

Marsh Posté le 04-03-2005 à 14:31:13    

Bonjour,
 
Je sais, dis comme ça, le sujet n'est pas très clair ...
 
Je travaille actuellement sur un programme sous Visual C++ 6.0. Systématiquement, il "plante" au même endroit du code (que ce soit en mode release ou debug).
En utilisant la version debug, je me suis rendu compte que, plus particulièrement, l'erreur se produisait dans la routine _heap_alloc_dbg
 qui est dans le fichier dbgheap.c (fichier situé à l'adresse "...\Microsoft Visual Studio\VC98\CRT\SRC" ). Dans celui-ci, j'ai les lignes suivantes :
 
....
 
lRequest = _lRequestCurr;
 
/* break into debugger at specific memory allocation */
if (lRequest == _crtBreakAlloc)
    _CrtDbgBreak();
 
....
 
Or, à le test se vérifie et la fonction _CrtDbgBreak() est appelée ce qui stop le programme.  
Est-ce que quelqu'un saurait à quoi correspond cette erreur et comment le résoudre ?
 
En regardant un peu, j'ai vu qu'il y avait un paramètre, \heap qui pouvait être indiqué dans les options de compilation et qui était lié à l'allocation de mémoire. Je l'ai augmenté (de 1 Mo à 4 Mo), mais le problème demeure.
 
Merci d'avance de votre aide.
 
Nathan_g

Reply

Marsh Posté le 04-03-2005 à 14:31:13   

Reply

Marsh Posté le 04-03-2005 à 14:35:01    

Non, l'erreur ne se produit pas dans debug_heap, mais c'est là qu'elle est détectée. Et windows t'ouvre gentiment une fenêtre pour t'indiquer que tu as un bug dans ton programme.
 
Il ne te reste plus qu'à trouver quel est le pointeur qui se balade dans ton code... (au pire, tu peux nous donner la fonction de ton code où ça plante).

Reply

Marsh Posté le 04-03-2005 à 14:49:16    

Je connais la fonction où ca plante. L'erreur se produit avec l'utilisation de la librairie Petsc (librarie de calcul scientifique), lorsque l'on cherche à allouer un tableau de variables de type PetscScalar. On a qqch du genre :
 
npetsc = 3
 
PetscScalar* TablePets = new PetscScalar [npetsc];
 
LA routine _heap_alloc_db est appelé dans le processus d'allocation de mémoire de ce tableau ce qui génère l'erreur.
 
En fait, en lançant mon calcul en mode Debug, avec les bonnes options de cochée, je pensais détecter l'erreur. En effet, j'avais demandé à Visual de signaler tout dépassement de tableau (Dans l'onglet Fortran, puis le choix "Run Time", j'ai coché les différentes possibilités - mon programme principal est en fortran et appelle des fonctions C++). Malheureusement, quand le programme s'arrête, je n'ai que l'indication donnée précédemment.
 
Y a t'il d'autres possibilités avec les options du mode Debug de Visual de de trouver "le pointeur qui se balade" dans mon code ?

Reply

Marsh Posté le 07-03-2005 à 11:21:10    

up

Reply

Marsh Posté le 08-03-2005 à 17:54:22    

essaye en ajoutant l'instruction
#define NEW DEBUG_NEW
 
dans stdafx.h ou n'importe quel autre fichier entête récurrent
dans ce cas, les informations fournies par le debugger de Visual sont plus poussées (ligne de code de l'objet non libéré...).
 
Ce mécanisme doit être référencé dans la MSDN...

Reply

Marsh Posté le 09-03-2005 à 10:03:31    

OK, Merci bcp
Je vais tenter ta correction.

Reply

Marsh Posté le 09-03-2005 à 11:02:38    

La détection des dépassements de tableau ça marche que pour la pile.
Si ton programme plante sur un new, c'est que l'erreur est avant encore (corruption du stack => new fait une vérif avant d'allouer : il est pas content).


---------------
FAQ fclc++ - FAQ C++ - C++ FAQ Lite
Reply

Marsh Posté le 09-03-2005 à 11:14:14    

Merci de ces précisions.
Effectivement, mon programme plante sur un New (allocation dynamique de méoire en C++). Je pensais arriver à trouver le problème en utilisant le Debugger mais il est rentré dans le code Visual jusqu'à trouver cette condition "lRequest == _crtBreakAlloc".
 
J'aurais préféré qu'il m'indique ce qui posait problème dans mon propre code ;) !
 
Quand tu parles de " corruption du stack ", HelloWorld, c'est que une partie de ma mémoire n'a pas été désallouée correctement ? (genre sortie d'une fonction sans désallocation des tableaux ou deux allocations d'un même tableau ... (on peut tout imaginer ;)), c'est ca ?
 
Dans ce cas, quand tu dis de faire une "vérif avant d'allouer", de quoi s'agit t-il ? Il faut vérifier si la zone mémoire que l'on cherche à allouer est libérée et ne contient pas de variables encore utilisée ? Il doit s'agir du "pointeur qui se balade dans mon code dont parle Lam's.
 
Est-ce qu'il est possible d'utiliser le Debuuger de Visual C++ 6.0 pour retrouver l'origine de ce genre de problèmes ?
 
J'ai quand même fait un affichage régulier de la mémoire utilisée par mon programme (avec le gestionnaire de tache) mais je n'ai pas détecté d'augmentation.

Reply

Marsh Posté le 09-03-2005 à 11:41:40    

Non, c'est new qui effectue des vérifications, notamment "lRequest == _crtBreakAlloc". L'erreur est avant l'appel à new, peut être bien avant...
Tout est possible : écrasement mémoire, double delete / utilisation du mauvais delete. Mais je penche plutot pour un dépassement de mémoire vu que la CRT vérifie les pblm de mauvais delete. Commence par rechercher le new qui précède celui qui plante et étudies comment tu te sert de la mémoire allouée...


---------------
FAQ fclc++ - FAQ C++ - C++ FAQ Lite
Reply

Marsh Posté le 15-05-2005 à 18:57:26    

Tu dois pouvoir remonter plus ou moins à l'origine du pb en remontant la pile d'appel des fonctions


Message édité par slash33 le 17-05-2005 à 13:43:26
Reply

Marsh Posté le 15-05-2005 à 18:57:26   

Reply

Marsh Posté le 19-05-2005 à 07:30:04    

euh, je suis nouvelle sur le forum et... traductrice.
est-ce que vous pouvez m'aider je ne comprends pas ce que veut dire "break into the debugger"
(additional code en a checked binat generates a kernel debugger error message and breaks into the debugger)
merci pour votre aide.

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed