Version imprimable
Bonjour à tous,
Je travaille actuellement sur un projet en WinAPI qui fonctionne bien, jusqu'au moment où l'on tente de fermer le programme. Alors, on obtient l'erreur suivante: "La mémoire à l'adresse 0x00000000 ne peut pas être read".
Si j'exécute le programme avec le débogueur, le problème ne se produit pas. Mais j'ai remarqué que 0x00000000 est l'adresse de retour située à la base de la pile d'appels.
J'utilise NetBeans 6.7.1 avec MinGW.
Merci d'avance pour votre aide.
C'est la valeur "nulle" utilisée par les pointeurs aussi.
A priori tu utilises un objet via un pointeur mais le pointeur est nul. Vérifie voir ce que tu manipules lorsque tu quittes ton programme. Si tu manipules des pointeurs a un endroit, fait une assertion vérifiant que les pointeurs sont nuls a chaque fois que tu en récupères un. Comme ça tu sauras rapidmenet où tu utilises un pointeur null.
En utilisant le débogueur de VC++, j'ai réussi à localiser la partie du code où ça coince. Seulement, je ne comprends ce qui pose problème dedans.
Voici le message d'erreur:Et voici le code en cause:Citation:
Exception de première chance à 0x7c921129 dans Analharm.exe*: 0xC0000005: Violation d'accès lors de la lecture de l'emplacement 0x003b7005.
La ligne qui coince est celle en gras.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18double** charger_courants (struct simulation* simul) { double** courants; int taille_tampon = 31 * simul->nb_pr + 15; char* tampon = NULL; char delimiteur[] = "\t"; char* champs = NULL; int i, pas; courants = (double **) malloc((simul->nb_pr + 1)*sizeof(double)); for (i=0; i<simul->nb_pr + 1; i++) { courants[i] = (double *) malloc((simul->duree + 1)*sizeof(double)); } tampon = (char*) malloc(taille_tampon*sizeof(char)); [...] }
Merci d'avance pour votre aide.
Quelle est la valeur du pointeur simul lorsque cela plante. (je parie pour un NULL)
Il est possible de voir la pile d'appel, les paramètres ainsi que les variables locales en utilisant le debuger de VC au moment du crash.
simul vaut 0x003b5c20 et simul->nb_pr vaut 1.
Et voici le contenu de la pile d'appels:
Citation:
ntdll.dll!7c921129()
[Les frames ci-dessous sont peut-être incorrects et/ou manquants, aucun symbole chargé pour ntdll.dll]
uxtheme.dll!5b0ac406()
uxtheme.dll!5b0ac3c8()
uxtheme.dll!5b091adb()
ntdll.dll!7c91cf7a()
ntdll.dll!7c92a2a3()
ntdll.dll!7c9218c0()
msvcr90d.dll!102c103e()
msvcr90d.dll!102cfd76()
msvcr90d.dll!102cfb2f()
msvcr90d.dll!102cfadc()
msvcr90d.dll!102db25b()
> Analharm.exe!charger_courants(simulation * simul=0x003b5c20) Ligne 27 + 0x16 octets C++
Analharm.exe!exploiter_saisie_simulation(simulation * simul=0x003b5c20) Ligne 776 + 0x9 octets C++
Analharm.exe!nouvelle_simulation(HWND__ * hWnd=0x001e084c, unsigned int uMsg=273, unsigned int wParam=40000, long lParam=0) Ligne 1174 + 0xc octets C++
Analharm.exe!MainWndProc(HWND__ * hWnd=0x001e084c, unsigned int uMsg=273, unsigned int wParam=40000, long lParam=0) Ligne 1429 + 0x15 octets C++
user32.dll!7e398734()
user32.dll!7e398816()
user32.dll!7e3989cd()
user32.dll!7e398a10()
Analharm.exe!WinMain(HINSTANCE__ * hinstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x00162359, int nCmdShow=1) Ligne 1481 + 0xc octets C++
Analharm.exe!__tmainCRTStartup() Ligne 578 + 0x35 octets C
Analharm.exe!WinMainCRTStartup() Ligne 403 C
kernel32.dll!7c817077()
devrait etreCode:(simul->nb_pr + 1)*sizeof(double)
ca marche quand meme car sizeof(double) >= sizeof(double*) mais n'empeche.Code:(simul->nb_pr + 1)*sizeof(double*)
tu appelles cette fonction plusieurs fois d'affilée ? ca plante a la combientieme fois ?
Exact. Merci pour la précision.
La fonction en question n'est appelée qu'une seule fois dans tout le programme.
la seule raison pour laquelle ca peut planter c'est que le tas est corrompu car le programme ecrit dans un des headers de mémoire peut-être.
utilise _CrtCheckMemory (http://msdn.microsoft.com/en-us/libr...8VS.80%29.aspx)
Alors, apparemment il y a bien un problème au niveau du tas. Voici le message renvoyé par _CrtCheckMemory:Citation:
HEAP[Analharm.exe]: Heap block at 003B68C8 modified at 003B68FC past requested size of 28
et ben mets en plein partout!
et lorsque la fonction plante, ca veut dire que la mémoire a été flinguée entre le dernier appel a _CrtCheckMemory (celui qui est pas content) et l'avant dernier appel. Essaye d'encadrer l'instruction qui écrit mal en mémoire. (Ca peut etre bien longtemps avant l'appel de ta fonction, qui a pas l'air d'être la coupable)
mmmm
quand je vois
je me pose des questions...Code:char* champs = NULL;
Au pluriel, cela signifierait "un tableau de champs"
Ce qui en C se traduirait par
avec les allocations subséquentes...Code:char** champs = NULL;
C'est vrai qu'écrire champs au pluriel peut être ambigu. Mais il s'agit bien d'une unique chaine de caractères et non d'un tableau de chaines.
J'ai corrigé les erreurs. Il y avait deux ou trois malloc foireux.
Merci à tous pour votre aide !
ah j'avais pas vu mon lien foireux, merci nicolas
pinaise j'ai fait ce copier coller sous linux je suis sur.... :calim2:
Bon, en fait, il reste un dernier souci mais je ne crois pas que ça soit de même nature que les précédents car CrtMemoryCheck ne renvoie pas d'erreur.
Le problème c'est que le programme est censé écrire dans un fichier, mais il n'écrit rien du tout et ne renvoie pas d'erreur... Une idée ?
Edit: En réalité, ça fonctionnait jusqu'à ce que j'enlève la partie test du code et que je rentre les données d'entrée dans les boites de dialogue. Or cela n'est pas censé affecter l'écriture du fichier.