Drole de bug avec Calloc !

Version imprimable

Voir 40 message(s) de cette discussion en une page

25/04/2007, 21h51
dmichel

1 pièce(s) jointe(s)

Drole de bug avec Calloc !

Bonjour a tous,

voila, j'ai cree un petit parser de commande, modeste et pas parfait mais suffisant pour mes besoins....

il fonctionne correctement mais cree un bug assez bizarre : les allocations memoires dynamiques, que j'effectue apres, plantent.
Les variables utilisees pour ces allocations n'ont apparement aucun lien avec le parser. Cependant, si j'ote le parser, tous va bien.... bizarre

encore plus bizarre, le code fonctionne parfaitement sous linux. sous windows avec devcpp..bug.

voici un code minimal qui demontre le probleme

merci d'avance pour votre aides

Dav
25/04/2007, 23h44
Thierry Chappuis
Citation:

Envoyé par dmichel

Bonjour a tous,

voila, j'ai cree un petit parser de commande, modeste et pas parfait mais suffisant pour mes besoins....

il fonctionne correctement mais cree un bug assez bizarre : les allocations memoires dynamiques, que j'effectue apres, plantent.
Les variables utilisees pour ces allocations n'ont apparement aucun lien avec le parser. Cependant, si j'ote le parser, tous va bien.... bizarre

encore plus bizarre, le code fonctionne parfaitement sous linux. sous windows avec devcpp..bug.

voici un code minimal qui demontre le probleme

merci d'avance pour votre aides

Dav

Salut,

Je n'ai pas regardé en détail, mais c'est pas beau à voir. Outre l'inclusion de l'en-tête iostream qui n'existe pas en C et les casts de calloc() qui sont déconseillés, je vois:
- Des variables globales: en as-tu réellement besoin?
- Que fait ta fonction allocationmem(), à part générer des trous de mémoire, parce que là, je vois pas? ())
De manière générale, tu ne vérifies jamais la valeur de retour de tes fonctions d'allocation dynamique. C'est une grosse erreur, tu devrais toujours le faire...

Thierry
26/04/2007, 01h22
souviron34
et c'est passé à la compile ça ???? sous Linux ????

:aie: 8O :roll: je te crois pas...

Au moins 2 énormités qui ne passent pas :
Code:

1 2 3 4 Opt_name[0] = "-h"; Opt_name[1] = "-c"; Opt_name[2] = "-p";
et
Code:

1 2 Opt_data[j] = cmd_v[i+k+1];
Les chaînes de caractères ne se copient pas comme ça, en C...

Il faut utiliser un strcpy, ou un strdup...

Comme tu as déjà alloué la mémoire, ça sera strcpy :
Code:

1 2 3 4 strcpy( Opt_name[0], "-h"); strcpy( Opt_name[1], "-c"); strcpy( Opt_name[2], "-p");
et
Code:

1 2 strcpy (Opt_data[j], cmd_v[i+k+1]);
26/04/2007, 11h24
dmichel

oups...j'avais pa fais gaffe a l'en-tête iostream...

mais a part ca...oui le code est assez brouillon avec des variable globales, etc...
mais ca n'explique pas le probleme ! La fonction allocationmem() ne fait rien en effet....car c'est juste un example !

Pourquoi est-ce que ca plante avec le parser ? pourquoi ca passe sans le parser?

sinon, ca compile sans problemes sous linux (as-tu essaye au moins ?)
et je vois pas le probleme avec

Code:

Opt_name[0] = "-h"

Du moment que Opt_name est definie comme

Code:

char **Opt_name

Il n'y a aucun problème à faire

Code:

Opt_name[0] = "-h"

sauf que tu as une fuite de mémoire puisqu'avant tu as alloué de la mémoire à Opt_name[0].
J'ai regardé ton code, à quoi sert cette fonction

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
void allocationmem(int bla)
{
 
int *gb_type,*gb_line,*gb_fill,*gb_trans,*gb_orient;
int *gb_type_old,*gb_line_old,*gb_fill_old,*gb_trans_old,*gb_orient_old;
int *gb_type_left,*gb_type_right;
 
printf("allocation...\n");
 
       gb_type = (int*)calloc(bla,sizeof(int));
       gb_fill = (int*)calloc(bla,sizeof(int));
       gb_line = (int*)calloc(bla,sizeof(int));
       gb_trans = (int*)calloc(bla,sizeof(int));
       gb_orient = (int*)calloc(bla,sizeof(int));
       gb_type_old = (int*)calloc(bla,sizeof(int));
       gb_fill_old = (int*)calloc(bla,sizeof(int));
       gb_line_old = (int*)calloc(bla,sizeof(int));
       gb_trans_old = (int*)calloc(bla,sizeof(int));
       gb_orient_old = (int*)calloc(bla,sizeof(int));
       gb_type_left = (int*)calloc(bla,sizeof(int));
       gb_type_right = (int*)calloc(bla,sizeof(int));
 
printf("allocation terminated\n");
 
}/*end function*/

Puisque tu alloues des variables qui ne sont pas utilisées ensuite ?

26/04/2007, 11h42
souviron34

Citation:

Envoyé par Trap D

Il n'y a aucun problème à faire

Code:

Opt_name[0] = "-h"

EN C ?????????????

que je sache "-h" est une chaîne de caractères, pas un caractère..

Et en C, la copie/assignation de chaîne se fait par strcpy..
26/04/2007, 13h03
dmichel

"-h" est en effet une chaine de character...c'est pour ca que Opt_name est un double pointer !! char **Opt_name ...c'est pas pareil que char Opt_name !!!

Bref, la question n'est pas la... la fonctione allocationmem() ne sert a rien dans cet example, c'est vrai. C'est juste un example. J'ai retire la suite du code pour que ca soit plus simple a lire.

mais il y a un test simple a faire....runner le code tel quel et runner le code sans la fonction custom_parser(). Voyez la difference...

avec la fonction custom_parser(), le code se plante dans allocationmem() et ne va pas jusqu'au bout (l'inscription "allocation terminated" ne s'affiche pas).
26/04/2007, 13h04
Trap D

Opt_name est de type char **, donc Opt_name[0] est de type char *.
[Edit] j'ai testé le code sous Vista avec Visual Studio 2005 pas de problème de plante.
[/edit]

et alors ?

ça marche bien dans son code il fait :
Code:

1 2 3 4 5 Opt_name = (char**)calloc(Num_opts,sizeof(char*)); for(i=0;i<Num_opts;i++){ Opt_name[i] = (char*)calloc(10,sizeof(char)); }
JE MAINTIENS LE strcpy ...............

26/04/2007, 13h23
Trap D

Nous sommes bien d'accord qu'il y a une fuite mémoire, mais on peut effectivement faire Opt_name[0] = "-h" (c'est une co***rie je te l'accorde :D )

Il a oublié aussi dans son code tous les free, c'est très mal programmé mais il n'y a pas de plante.
26/04/2007, 13h26
dmichel

Citation:

Envoyé par Trap D

j'ai testé le code sous Vista avec Visual Studio 2005 pas de problème de plante.

Haha...car sous WinXP avec devcpp, ca plante. J'ai d'abord pense que le compilateur en avait un coup dans le nez...alors j'ai deinstalle et reinstalle devcpp, mais la meme chose se produit. Sous linux, pas de problemes.
26/04/2007, 13h31
dmichel

Citation:

Envoyé par Trap D

Nous sommes bien d'accord qu'il y a une fuite mémoire, mais on peut effectivement faire Opt_name[0] = "-h" (c'est une co***rie je te l'accorde :D )

Comme je l'ai dis precedemment...c'est un brouillon :)

Citation:

Envoyé par Trap D

Il a oublié aussi dans son code tous les free, c'est très mal programmé mais il n'y a pas de plante.

j'ai enleve beaucoup du reste du code pour simplicite.... mais apparement, ca prete a confusion... desole.

Mais comme tu l'as dis...c'est mal ecrit, mais ca devrait pas plante pour autant...

il faudrait que quelqu'un avec Devcpp essaye
26/04/2007, 13h34
souviron34

Citation:

Envoyé par Trap D

Nous sommes bien d'accord qu'il y a une fuite mémoire, mais on peut effectivement faire Opt_name[0] = "-h" (c'est une co***rie je te l'accorde :D )
.

Je ne crois pas. Ce n'est pas une initialisation dans une déclaration. C'est en cours d'exécution. Et je met ma main à couper que tout ce que ça fait, c'est mettre une adresse dans Opt_name[0][0] , ou à la limte le caractère '-'. Sans plus.
26/04/2007, 13h37
dmichel

Citation:

Envoyé par souviron34

Et je met ma main à couper que....

c'est dommage, j'ai pas de hache

si tu essayais le code, tu verrais qu' il n'y a pas de problemes
26/04/2007, 13h39
souviron34

1) ce n'est pas parce qu'il n'y a pas de problème que ça marche
2) yen a ben un, problème, puisque tu plantes..

c'est juste que ça dépend des tolérances et des environnements.
26/04/2007, 13h49
dmichel

selon moi, Opt_name[0][0] aura le character "-" et Opt_name[0][1] aura "h"
en tous cas c'est ce que je veux avoir....ok il y aura une fuite de memoire car l'allocation memoire precedent permet 10 characters

et donc, selon toi, ca causerait le plantage dans les callocs comme celui ci

gb_orient = (int*)calloc(bla,sizeof(int));

....mmmm, la je vois pas...faut m'expliquer
26/04/2007, 13h52
souviron34

je répète juste que la manière correcte (indépendamment de ce qu'en fait le compilo ou le RAD), en C, de copier une chaîne est strcpy...
26/04/2007, 13h56
dmichel

ok...il faut que j'essaye ca. Mais la je suis sur linux au boulot donc j'essayerais ce soir
26/04/2007, 15h01
droggo

Hoal,

Citation:

Envoyé par dmichel

Haha...car sous WinXP avec devcpp, ca plante. J'ai d'abord pense que le compilateur en avait un coup dans le nez...alors j'ai deinstalle et reinstalle devcpp, mais la meme chose se produit. Sous linux, pas de problemes.

Avant de penser ce genre de truc, il faut faire du code propre et, au minimum, correct.

Je ne doute pas que tous les compilateurs aient quelques petits bugs de-ci de-là, mais avant d'accuser ton compilateur, il faut.... retour au 1er paragraphe.
26/04/2007, 15h13
Trap D

Citation:

Envoyé par souviron34

Je ne crois pas. Ce n'est pas une initialisation dans une déclaration. C'est en cours d'exécution. Et je met ma main à couper que tout ce que ça fait, c'est mettre une adresse dans Opt_name[0][0] , ou à la limte le caractère '-'. Sans plus.

Opt-name[0] étant un pointeur vers une chaîne de caractères, qu'il soit initialisé par un malloc ou par l'adresse d'une chaîne codée en dur en mémoire, je ne vois pas où est le problème.
Son programme plante peut-être à cause de cette manipulation Opt_data[j] = cmd_v[i+k+1]; un peu bizarre dont je viens de m'apercevoir et qui avec cette combiansion d'arguments doit donner des résultats incorrects.

Voir 40 message(s) de cette discussion en une page