salut,
 
dans un programme, je fais un malloc et ca plante a ce moment la ... j'ai droit a un access violation !
Quelqu'un a une idée ?

slt,
 
généralement quand on fait un malloc et que ça plante et que tu as assez de mémoire, alors c'est que t'as un autre pointeur ailleur qui a deja foutu ça merde. enfin c'est une possibilité.
 
Petit rappelle, au débutant en C, a chaque malloc que vous faites vous créez de suite le free qui va avec.
 
Faites vos malloc de pref en début de fonction et vos free en fin (si possible) Les malloc calloc,free a l'interieur de fonction c'est une plaie !

[edtdd]--Message édité par barbarella--[/edtdd]

barbarella > voui...
Juste une note certains compilo integrent des fct comme _alloca ou _alloca_ou __alloca ou stack_alloc qui permttent d'alouer la memoire sur la pile, donc l'allocation est rapide et la desalocation implicite en fin de fct... malheureusement ces fcts ne sont pas standard.

le realloc marche pas mal . .enfin quand on ne l'utilise pas trop ;-) apparement au delà d'un certain nombre de fois il plante mais il a l'avantage de ne plus se soucier de la nouvelle adresse du pointeur à qui on a alloué de la nouvelle memoire

Un malloc qui a pas assez de mémoire fait pas d´access violation!!
 
Chapi chapi chapo cherche donc une autre cause que ds malloc lui même.. En tt cas moi j´ai jamais vu ça..

chapo chapo chapi,
 
J'ai généralisé mon propos sur les pointeurs, t'as pas vu ...

balance ton code si possible

H4dd3R a écrit a écrit : Un malloc qui a pas assez de mémoire fait pas d´access violation!!   Chapi chapi chapo cherche donc une autre cause que ds malloc lui même.. En tt cas moi j´ai jamais vu ça..

 
Comme l'a dit barbarella, un malloc qui fait un Access Violation ne peu venir, a mon avis, que d'une structure memoire corrompue, le preobleme est donc anterieur, a chercher avec un purify ou qq chose comme ca...

euh... plus simplement...
 
Peut-être que tu essaies d'allouer une quantité négative de mémoire ?
Ou alors tu ne vérifies pas la valeur de retour du malloc (si c'est NULL en cas de non-allocation, bonjour les dégats après )

c'est marrant,
 
je viens juste d'en avoir une cet aprem. Après un copier/coller puis quelque del/ins pour bien aligner le texte je me suis retrouvé avec  
 
char *buffer;
buffer = (char *)malloc(2000);
....
a += sprintf((buffer+a),".." );
.....
printf("%s",buffer);
buffer = '\0';
...
free(buffer);
 
 
y a eu un del de trop sur une ligne. A l'execution buffer = '\0'; donne un access violation chez moi. manque le *

merci pour tous ses avis ...
explication du probleme ...
je lis un fichier palm et je rempli une structure en memoire, jusque la, tout allait bien car depuis une semaine, lors de l'allocation de la structure, ca plante...
 
Pour les problemes de Free, je les libere a la fin du programme mais c'est pas ca le probleme (y'a de la place en mémoire et pis si je libere pas, le malloc va pas alloué cette mémoire, au pire, j'en aurai plus de dispo mais je m'en fous pour le moment !)
 
Voila le code incriminé !!
 
for (int i=0;i<applResource->numRecord;i++) {
   resource[i].data = (char*) malloc (sizeof(char) * resource[i].size);
   ReadFile( prcFile, resource[i].data, resource[i].size , &result,  NULL );  
}
 
- applResource->numRecord donne le nombre de structures dans le fichier palm (c'est bien initialisé !)
- resource[i].data : c'est un pointeur de char non encore initialisé.
- resource[i].size : nombre de caractere a lire dans le fichier et a mettre en memoire !
 
Ca plante quand i = 3 !
 
Voila, je reste dispo pour d'autres infos !

je rajouterai que l'acces violation a lieu sur la ligne du malloc , pas apres !

un ptit effort svp !!

On sait jamais, et si c´était pas le malloc??
 
Tu es sûr que resource[3] existe??
 
 

bein tenté mais ... oui, il existe ... ca va jusqu'a 23 !!
 
je fais ca avant de travailler dessus !
 
resource = (Resource*) malloc (sizeof(Resource) * applResource->numRecord);

slt,
 
a priori j'écrirais la ligne :
 
resource[i].data = (char*) malloc (sizeof(char) * resource[i].size);  
 
Comme ça :
resource[i].data = (char *) malloc(resource[i].size+1);
 
 
- j'ai un doute s'il existe une diff entre (char*) et (char *)  
- sizeof(char) est toujorus égale a 1, aux dernières nouvelles
- +1 pour le caract de terminaison de fin de chaine (c'est pus une sécurité qu'autre chose, mais ça m'a des fois sauvé une journée de boulot

ok, je vais essayer avec le +1 mais bon ca m'etonnerai que ca soit ca car c'est un fichier binaire donc y'a pas d'octet d'arret !
De plus pour le sizeof(char), c'est parce que je bosse sur des PDA et on sait jamais ... entre le palm et le pocket, y'a des differences super chiantes alors je prefere assurer ...
par exemple int : palm  = 2 octets et pocket = 4 octets ! et on pense pas forcement a verifier !!

pense aussi au char *, je suis en train de vérifier mais bon ...
 
pour l'int par défintion dans le C sa taille est dépendante de la taille des registres généraux utilisés. processeur 16 bits int = 16 proc, 32 int = 32, .... c'est ce qui différencie 'long' et 'int'. enfin si mes souvenirs sont bons

[edtdd]--Message édité par barbarella--[/edtdd]

c'est tout a fait ca mais bon, je reprend un prog pour palm et le mec qui avait fait ce verifiait pas les tailles des int.
Maintenant,  j'utilise plus que des short ou des longs, ca regle le probleme !
 
Je pense pas que char* et char * soient differents !
 
Le pire c'est que si je change de fichier ca marche ... et la difference entre les 2 c'est juste le contenu des structures, pas leur nombre !!
 
Trop zarbe ce probleme !

sinon vraiment au pif,
 
c'est le coup des unsigned char et char. n'oublie pas que si la valeur de char > 127 elle devient négative pour char. Je ne sais pas trop quel type d'erreur ça génére, faut juste controler la correspondance exacte des types.

ca c'est pas mon probleme a cette endroit du programme ...
Plus tard je m'en occupe (ca depend de la partie du fichier palm, y'a des chaines en char et du binaire en unsigned char ...)
 
Merci d'essayer !

barbarella a écrit a écrit : slt, .... - sizeof(char) est toujorus égale a 1, aux dernières nouvelles - +1 pour le caract de terminaison de fin de chaine (c'est pus une sécurité qu'autre chose, mais ça m'a des fois sauvé une journée de boulot

 
Non, sizeof(char) = 4 ici !
sizeof(short) = 4
sizeof(int) = 4
sizeof(long) = 8 !
donc (char*)(malloc(sizeof(char)*(taille+1)))

[edtdd]--Message édité par BENB--[/edtdd]

 
Ca fait une table de 4294967296 caractères ca
Simple curiosité : quoi ça ?

slt BENB,
 
------------------
Non, sizeof(char) = 4 ici !  
sizeof(short) = 4  
sizeof(int) = 4  
sizeof(long) = 8 !  
donc (char*)(malloc(sizeof(char)*(taille+1)))  
-------------------
 
T'explique ta bombe la, parceque je suis curieux surtout pour le sizeof(char) = 4

tgrx & barbarella > Station HP 64 bits avec certaines options d'alignement...

oui mais pourquoi des char de 4 octets et pas 2 ?
2 ca suffit pour de l'unicode non ?
 
un char doit être utilisé pour des caractères non ? ou alors y a qq chose qui m'échappe...

 
Non, la norme Unicode n'a pas fixé la longueur d'un caractère Unicode à 2 octets, c'est variable .

ok,
 
c'est du C ANSI ça ? enfin bon que ça existe je ne le remets pas en cause et merci pour l'info.
 
 
Il n'empeche que pour la gestion, le compil fait-il de la concaténation, car même si les tableaux de char sont codés sur 2^16 je ne m'imagine pas des tables de char sur 2^32. quel est l'imbécile qui gère 4 milliard de symboles ? Donc une zone de char en 2^32 peut contenir 4 char d'une table de symbole 2^8 ou 2 d'une table de 2^16 symboled.
 
s'ils n'utilisent pas la concaténation, alors je dis qu'il y a du gaspillage

je pense que t'as pas d'autre solution que de donner ton code au complet avec tes fichiers. Moi je veux bien tester pour toi si tu veux si ça tourne sur pc évidemment.

tgrx & barbarella > c'est du C++
et si tu fais char u = 2000; le compilo te jette...
mais si tu fais sizeof() tu obtiens 4...
C'est pas de l'unicode, c'est l'alignement... en changeant les options de compil tu aura d'autres resultats...
 
De plus dans le Bjarne il donne aussi cet exemple...
en C++ la seule garantie
est sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)
il peuvent tous faire 32 bits...

oui mais peut-on faire confiance à Bjarne en ce qui concerne le C++, voila la question....
 
 
 
(désolé, chuis crevé today... )

ouais,
 
ok c'est bon je ferais attention à l'avenir. Par contre je ne comprends pas l'int en 4 octets sur un proc 64 bits pour l'HP. il devrait s'aligner sur 8 ?
 
Pour l'histoire de l'alignement avec les char j'attendrais d'avoir un compilateur mise a jour, je ne suis pas sur que le mien gère ça correctement et même si, il n'est pas sur que les réactions soit les mêmes entre un windoz/PC et un HP7000/9000 (je suppose que tu penses a ces betes là ?).  
 
y a personne qui aurait un vieux VC++6 qui traine dans sa poubelle par hasard

[edtdd]--Message édité par barbarella--[/edtdd]

barbarella > oui PA 2.0...
avec une option d'alignement 32 bits...
sans cette option le char redeviens sizeof(char) = 1...
 
sinon le int est 32 bits  
le long et les pointeurs 64 bits...
 
minusplus> a qui fais-tu confiance ?

 
Dsl, il y a 2 raisons pour lesquelles je peux pas donner mon code :  
1) c'est secret defense ...  
2) ca tourne sur IPAQ !!
 
d'autre part, j'ai essayer de changer le code en allouant un gros bloc de memoire (plus grand que necessaire !!) et d'aller piocher dedans .. on dirait que ca marche .. je vous tiens au courant !

BENB> ah oué    
'tain je suis pas très en forme aujourd'hui    
 
enfin cette histoire d'alignement sur 4 octets est-ce vraiment utile ?? chaque processeur moderne peut adresser à l'octet pret non ? (et hop deuxième connerie de la journée   )
 
Bjarne mais bon 1000 pages ca fait beaucoup à lire, je ne prétends pas connaître son bouquin par coeur

tgrx a écrit a écrit : BENB>   enfin cette histoire d'alignement sur 4 octets est-ce vraiment utile ?? chaque processeur moderne peut adresser à l'octet pret non ? (et hop deuxième connerie de la journée   )

bah oui mais surement moins vite selon la taille de ses registres... (je suppose)

tgrx & minusplus > cet alignement est une option non documente, utilisee ici... Perso je trouve ca un peu con car dans la pratique quand on traite une chaine...
Mais ils disent que la difference de vitesse justifie la chose...
Il faut dire que c'est pas le manque de memoire vive qui nous etrangle... env 16 Giga (RAM)... Le probleme c'est vraiment la vitesse...
 
Chapi456 > est tu sure que ton Pb ne viennent pas du +1 qui manque...
strlen ne compte pas le 0 final !

Chapi456 ,
 
 
l'allocation supplémétaire c'est souvent un truc du genre reculer pour mieux sauter.
 
tu devrais décomposer ta boucle en 2, l'une pour les allocation l'autre pour la lecture. Dans la lecture teste si il y a une erreur de lecture, parfois une telle erreur peut provoquer des trouvle dans les pointeurs.
 
Dans la boucle des malloc fait aussi un memset ou alors utilise un calloc. le faite de faire une init des pointeurs permet de tester s'ils ont été bien alloués, car un pointeur mal alloué ne pourra pas supporter un memset.

barbarella ...
 
Je fais pas d'allocation supplémentaire, j'en fais une seule et ensuite je fais pointer mes structures sur des bouts de ce gros morceau de memoire.
 
Je vais essayer le memset pour voir ce que ca donne !