 |
||
| ||
| |||||
| Dernière réponse | |
|---|---|
| Sujet : access violation ... avec un malloc !! | |
| chapi456 | 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 ! |
| Aperçu |
|---|
| Vue Rapide de la discussion |
|---|
| chapi456 | 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 ! |
| barbarella | 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. |
| BENB | 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 ! |
| minusplus |
|
| tgrx | BENB> ah oué :crazy: 'tain je suis pas très en forme aujourd'hui :p 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 :sweat: ) Bjarne :jap: mais bon 1000 pages ca fait beaucoup à lire, je ne prétends pas connaître son bouquin par coeur |
| chapi456 |
|
| BENB | 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 ? :D |
| barbarella | 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 :D [edtdd]--Message édité par barbarella--[/edtdd] |
| minusplus | oui mais peut-on faire confiance à Bjarne en ce qui concerne le C++, voila la question....
(désolé, chuis crevé today... :D ) |
| BENB | 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... |
| ayachi | 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. |
| barbarella | 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 |
| zop |
|
| tgrx | 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... |
| BENB | tgrx & barbarella > Station HP 64 bits avec certaines options d'alignement... |
| barbarella | 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 |
|
| BENB |
[edtdd]--Message édité par BENB--[/edtdd] |
| chapi456 | 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 ! :sol: |
| barbarella | 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. |
| chapi456 | 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 ! |
| barbarella | 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 :D [edtdd]--Message édité par barbarella--[/edtdd] |
| chapi456 | 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 !! |
| barbarella | 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 ;) |
| chapi456 | 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); |
| H4dd3R | On sait jamais, et si c´était pas le malloc??
Tu es sûr que resource[3] existe?? :) :) |
| chapi456 | un ptit effort svp !! :bounce: |
| chapi456 | je rajouterai que l'acces violation a lieu sur la ligne du malloc , pas apres ! |
| chapi456 | 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 ! |
| barbarella | 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 * |
| tgrx | 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 :sol: ) |
| BENB |
|
| ayachi | balance ton code si possible:) |
| barbarella | chapo chapo chapi,
J'ai généralisé mon propos sur les pointeurs, t'as pas vu ... ;) |
| H4dd3R | 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.. :) |
| la viper | 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 |
| BENB | 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. |
| barbarella | 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] |
| chapi456 | 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 ? |
