Probleme étrange avec realloc ...

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : Probleme étrange avec realloc ...

rital_5_4

Bonjour à tous,

Je m'adresse à vous car j'ai un étrange problème avec realloc. Apparemment c'est lui le fautif :lol: .

Je m'explique voici mon code :

Code :

typedef struct {
....
}montype;
typedef struct tab{
montype* element;
int taille;
}tab;
void ajouterE(tab t){
element e;
initialiserElement(&e);
t.taille += 1;
montype* tmp;
tmp = (montype*)realloc(t.element,t.taille* sizeof(montype));
if(tmp == NULL){
exit(5);
}
else{
t.element = tmp;
t.element[t.taille-1] = e;
}
}

L'affectation en rouge fait tout planter ... (sgmentation fault) alors que l'instruction t.element[t.taille-1]; passe lors de l'execution. Est ce que quelqu'un sait pourquoi? :jap:

Merci d'avance!

Message cité 1 fois

Publicité

olivthill

Au lieu de realloc(), il paraitrait plus logique de faire appel à malloc(), car il semble que tmp n'a jamais été alloué avant. Cela dit, je ne sais pas si c'est ça qui cause le problème.

Message cité 2 fois

Elmoricq

Modérateur

Que fait la fonction initialiserElement() ?
Normal que tu enregistres un "element" dans une variable de type "montype", ou c'est juste une erreur de copier/coller ?

olivthill a écrit :

Au lieu de realloc(), il paraitrait plus logique de faire appel à malloc(), car il semble que tmp n'a jamais été alloué avant. Cela dit, je ne sais pas si c'est ça qui cause le problème.

"tmp" n'est pas utilisé parce que c'est la variable temporaire pour recevoir le résultat de realloc().
C'est la structure "t" qui est importante ici, et elle contient peut-être déjà des choses, surtout vu le nom de la fonction.

Message édité par Elmoricq le 23-03-2006 à 17:23:14

olivthill

Oui, tu as raison Elmoricq, ma remarque n'est pas judicieuse car, en effet, on a le droit de faire ce genre de réallocation, même si jusqu'à présent, je n'avais vu que des realloc sur soi-même.

Elmoricq

Modérateur

C'est une réallocation sur "soi-même".

La fonction s'applique bien sur t.element.
Traditionnellement, on assigne le résultat de realloc() à une variable temporaire, car si realloc() échoue et retourne NULL, la variable initiale (ici, t.element) est toujours valide.
L'utilisation d'une variable temporaire permet donc de continuer le programme sans perdre l'adresse du pointeur d'origine (même si ici l'intérêt est limité puisqu'un échec de realloc() est suivi d'une sortie du programme).

skelter

faudrais plutot passer l'adresse de tab à la fonction (la tu modifie une copie locale)

Sve@r

rital_5_4 a écrit :

Code :

typedef struct {
....
}montype;
typedef struct tab{
montype* element;
int taille;
}tab;
void ajouterE(tab t){
element e;
initialiserElement(&e);
t.taille += 1;
montype* tmp;
tmp = (montype*)realloc(t.element,t.taille* sizeof(montype));
if(tmp == NULL){
exit(5);
}
else{
t.element = tmp;
t.element[t.taille-1] = e;
}
}

1) ta fonction "ajouterE" reçoit une copie de ta variable que tu lui passes. Et copier une structure n'est pas du tout une bonne idée. Surtout que avec ton realloc tu ne modifies que le pointeur copié et non le pointeur original.

2) ta variable "e" est une variable de type "element" or, dans cette partie de code, le type "element" n'existe pas. Peut-être que tu voulais écrire "montype e"...
De toute façon la variable "e" est locale donc elle sera définitivement perdue lorsque tu quitteras la fonction. Or tu la copies dans t.element[...]. Si c'est un type simple, ça va mais si "e" est structurellement plus complexe, tu risques de ne copier que des ombres. A la limite en mettant "e" en static tu peux t'en sortir mais d'une façon générale, il y a quand-même un pb de conception d'où ton erreur sur le realloc qui est caractéristique d'une fuite de mémoire

olivthill a écrit :

Au lieu de realloc(), il paraitrait plus logique de faire appel à malloc(), car il semble que tmp n'a jamais été alloué avant. Cela dit, je ne sais pas si c'est ça qui cause le problème.

On a tout a fait le droit de faire du realloc même sur une variable qui n'a jamais été allouée mais faut qu'elle soit initialisée à "NULL" (le realloc fait alors un simple malloc). Cela permet de faire des boucles de realloc sans être obligé d'écrire le malloc initial...

Message édité par Sve@r le 23-03-2006 à 19:07:16

---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.

rital_5_4

Citation :

ta variable "e" est une variable de type "element" or, dans cette partie de code, le type "element" n'existe pas. Peut-être que tu voulais écrire "montype e"...

Effectivement il y a une faute de frappe la variable e est de type montype en réalité veuillez m'exuser :jap: !

Citation :

Et copier une structure n'est pas du tout une bonne idée. Surtout que avec ton realloc tu ne modifies que le pointeur copié et non le pointeur original

Je n'ai pas vraiment le choix ici ... désolé je ne suis pas un pro en c ^^ ... y a t-il une autre solution plus propre?

Citation :

De toute façon la variable "e" est locale donc elle sera définitivement perdue lorsque tu quitteras la fonction. Or tu la copies dans t.element[...]. Si c'est un type simple, ça va mais si "e" est structurellement plus complexe, tu risques de ne copier que des ombres.

.
Ouais en fait e contient elle même un tableau 2D et des attributs entiers ect ... et c'est meme pire que de l'ombre ca fait tout planter...

Citation :

A la limite en mettant "e" en static tu peux t'en sortir mais d'une façon générale, il y a quand-même un pb de conception d'où ton erreur sur le realloc qui est caractéristique d'une fuite de mémoire

Le coup du static pourquoi pas je peux essayer si ca marche mais c'est sure que si je peux éviter .

Citation :

Que fait la fonction initialiserElement() ?

Pas grand chose elle se contente d'initialiser la taille du tableau à 0.

Citation :

faudrais plutot passer l'adresse de tab à la fonction (la tu modifie une copie locale)

Je peux essayer effectivement vu que le tableau est déclaré dans le main. Mais qu'entend tu par modifier une copie locale ?

Message édité par rital_5_4 le 23-03-2006 à 19:55:10

skelter

les parametres sont passé par valeur en C

le prototype doit plutot etre
void ajouterE(const montype * e);

rital_5_4

C'est a n'y rien comprendre la déclaration tab montableau; provoque une erreur de segmentation .... je n'y comprend plus rien.

Sinon pour le static c'est rapé je viens de tester.

Voici le nouveau code qui n'a pas l'air de marcher beaucoup mieux avec le passage de tableau par adresse :

Code :

void ajouterE(tab* t,montype e){
(*t).taille += 1;
montype* tmp;
tmp = (montype*)realloc((*t).element,(*t).taille* sizeof(montype));
if(tmp == NULL){
exit(5);
}
else{
(*t).element = tmp;
(*t).element[(*t).taille-1] = e;
}
}

OU ALORS procéder comme ci-dessous :

Sinon est-il possible de passer l'élément de type montype par adresse et de faire une affectation du genre (*t).element[(*t).taille-1] = (*r); enfin dans cet esprit...
En disant ca je pense a passer e en adresse et de recopier les champs 1 à 1 comme ceci par exemple

(*t).element[(*t).taille-1].x = (*e).x;

Message cité 1 fois
Message édité par rital_5_4 le 23-03-2006 à 20:23:06

Publicité

skelter

Citation :

Voici le nouveau code qui n'a pas l'air de marcher beaucoup mieux avec le passage de tableau par adresse

passage de l'adresse du tableau [:aloy]

tu peux remplacer (*t). par t->

Citation :

Sinon est-il possible de passer l'élément de type montype par adresse et de faire une affectation du genre (*t).element[(*t).taille-1] = (*r); enfin dans cet esprit...

oui

Citation :

void ajouterE(tab* t,const montype * e){...}

skelter

Citation :

En disant ca je pense a passer e en adresse et de recopier les champs 1 à 1 comme ceci par exemple

(*t).element[(*t).taille-1].x = (*e).x;

affectation ou memcpy suffit

rital_5_4

Citation :

tu peux remplacer (*t). par t->

Quelle est la différence, j'ai essayé le cout du const ca n'a pas l'air de marcher mais par contre ce qui est bizar c'est que l'instruction tab tableau; donne lieu à un segmentation fault sauf a la premiere execution. Je pense que la mémoire doit être corrompu dans le tas à un endroit et que après les executions suivantes plantent. Qu'en pensez vous?

Ca m'embete vraiment cette histoire car j'ai besoin de cette fonction :cry:

Message édité par rital_5_4 le 23-03-2006 à 23:18:40

rital_5_4

Je reposte tout le code au cas ou :

Code :

void initTableau(tab* t){
(*t).taille = 0;
}
void ajouterE(tab* t,const montype* e){
(*t).taille += 1; // On augmente la taille
montype* tmp;
tmp = (montype*)realloc((*t).element,(*t).taille* sizeof(montype));
if(tmp == NULL){
exit(5);
}
else{
(*t).element = tmp;
(*t).element[(*t).taille-1] = (*e);
}
}
int void main(){
...
tab tab2; // Plantage parfois lors le l'execution
initTableauR(&tab);
...
montype e;
ajouterE(&tab2,&e); // Plantage total ....
}

olivthill

Peut-être qu'en montrant encore un peu plus de code, cela aiderait.

Message cité 1 fois
Message édité par olivthill le 23-03-2006 à 23:58:10

skelter

Citation :

Quelle est la différence

c'est la meme chose, mais la syntaxe "->" est quand meme moin lourde

Citation :

Code :

tmp = (montype*)realloc((*t).element,(*t).taille* sizeof(montype));

c'est quand meme plus claire comme ca

Code :

tmp = realloc(t->element, t->taille * sizeof *tmp);

rital_5_4

olivthill a écrit :

Peut-être qu'en montrant encore un peu plus de code, cela aiderait.

Et bien a priori pour chaque nouvelle élément j'ai une fonction qui l'initialise :

Code :

void initElement(montype* e){
(*e).u = a;
(*e).v = b;
(*e).t = z;
.....
(*e).tableau= f1();; // Avec f1 qui retourne un tableau ayant été alloué dynamiquement au préalable
}
int main(){
....
montype e;
initElement(&e);
}

Je precise que quand je fait des trucs du genre tout marche parfaitement ...

Citation :

int main(){
....
montype e,e1;
initElement(&e);
initElement(&e1);

funct(&e) ....
}

Peut être manque t-il quelque chose effectivement ... :pt1cable:

Message édité par rital_5_4 le 24-03-2006 à 00:19:05

skelter

montre en plus

rital_5_4

Code :

typedef struct {
int toto;
int tutu;
}montype2;
montype2** f1(){
allocation dynamique ..........
}

Message édité par rital_5_4 le 24-03-2006 à 00:25:23

skelter

pourquoi le type retour est montype2** ?

essaies de montrer du vrai code (celui dont tu doutes, genre les allocations), avec ca c'est difficile de t'aider

Message cité 1 fois

rital_5_4

skelter a écrit :

pourquoi le type retour est montype2** ?

essaies de montrer du vrai code (celui dont tu doutes, genre les allocations), avec ca c'est difficile de t'aider

Parce que la structure montype contient elle meme un tableau de type montype2 (montype.tableau = tableau 2d de type montype2) je sais que c'est le bordel ^^ sinon pour le code des allocations ca donne ca :

Code :

montype2** f1(int x,int y){
montype2** s;
//allocation dynamique
s = (montype2**)malloc(sizeof(montype2*)*y);
int i,j;
for(i=0; i < hauteur; i++){
s[i] = (montype2*)malloc(sizeof(montype2)*x);
}
// initialisation des elements
for(i=0; i < x; i++){
for(j=0; j < y; j++){
s[i][j].toto= 0;
}
}
return s;
}

Message édité par rital_5_4 le 24-03-2006 à 00:43:27

skelter

#
for(i=0; i < x; i++){
#
for(j=0; j < y; j++){
-->
#
for(i=0; i < y; i++){
#
for(j=0; j < x; j++){

t'as inversé x et y

Sve@r

rital_5_4 a écrit :

C'est a n'y rien comprendre la déclaration tab montableau; provoque une erreur de segmentation .... je n'y comprend plus rien.

Bon, on arrête la souffrance. J'ai l'impression que tu veux créer une fonction qui ajoute un certain type d'élément à la fin d'un tableau non ???

Bon, on y va (sur un air de Raphael, ça va m'aider à taper sereinement...) - Je te fais un exemple à l'image de ton premier post...

Code :

// Définition de la structure permettant de gérer un type complexe
typedef struct {
int x;
int y;
int z;
... // Tout ce que tu veux
} t_montype;
// Définition de la structure permettant de gérer un tableau de types complexes
typedef struct {
t_montype *listeElement;
size_t nbElement;
size_t taille;
} t_tab;
// Fonction permettant d'initialiser une "t_montype"
void initialiserElement (t_montype *pt)
{
pt->x=...;
pt->y=...;
pt->z=...;
}
// Fonction permettant d'ajouter un élément dans mon tableau
int AjouterElement(t_tab *tab)
{
t_montype elem;
// Initialisation de l'élément
initialiserElement(&elem);
// Si le nb d'élément déjà présents a atteint la taille allouée => le nouveau ne tiendra pas
if (tab->nb_elem == taille)
{
// On agrandit la taille (de 100 par exemple)
tab->taille+=100;
// on réalloue un tableau plus grand
tab->listeElement=realloc(tab->listeElement, taille * sizeof(t_element));
// Réallocation échouée => fin fonction
if (tab->listeElement == NULL)
return(-1);
}
// On copie l'élément initialisé à son emplacement
memcpy(&tab->listeElement[nb_elem], &elem, sizeof(t_element));
// On incrémente le nb d'éléments
tab->nb_elem+=1;
// on renvoie une valeur pouvant signifier "ok" (ce qu'on veut sauf "-1" )
return(tab->taille);
}
// Fonction principale (qui est "int", pas "int void" !!!)
int main()
{
// Création de mon tableau
t_tab tab;
int i;
// Initialisation tab (obligatoire)
tab.listeElement=NULL;
tab.nb_elem=0;
tab.taille=0;
// Remplissage de "n" éléments
for (i=0; i < ...; i++)
{
if (ajouterElement(&tab) == (-1))
{
printf("Echec ajout i=%d\n", i);
exit(-1);
}
}
// Ici, mon tableau est rempli
....
}

La principale différence avec ton premier programme, c'est que je passe par "memcpy" pour copier ma variable "e". "memcpy" copie tous les octets de "e" dans la zone destinatrice. Si "e" ne contient pas de pointeur, c'est bon. "memcpy" est la fonction à utiliser quand on doit copier une variable complexe dans une autre à condition que la variable ne contienne pas de pointeur. Si c'est le cas, alors c'est à toi de te créer la fonction de copie spéciale qui ira allouer dans la zone réceptrice les pointeurs et y copier ceux de la zone émettrice.

Quelques petites différences avec ton pgm
- je passe par une variable "taille" me donnant la taille allouée. Cela me permet de ne pas appeler "realloc" (gourmand) à chaque ajout... mais m'oblige à allouer des blocs de 100 "t_element". L'avantage de cette méthode est que tu peux paramétrer facilement le nb de blocs (en le mettant à "1", cela revient à faire comme t'avais fait)
- nommer ses types "t_qqchose" est assez recommandé - permet d'éviter plus tard de les confondre avec des variables.
- je ne passe pas par un pointeur intermédiaire pour realloc. Etant donné que si realloc échoue, cela ne m'intéresse pas de garder ma liste puisque je ne peux pas m'en servir. Mais rien ne t'interdit d'en utiliser un si t'en as envie
- ma fonction "ajouter" renvoie un code spécial quand elle échoue... et c'est la fonction appelante qui gère en fonction du code reçu. Ne jamais faire de "exit" brutaux dans une sous-fonction => horrible
- j'espère que tu remarques l'utilité des commentaires...

---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.

skelter

Citation :

"memcpy" est la fonction à utiliser quand on doit copier une variable complexe dans une autre à condition que la variable ne contienne pas de pointeur

oui, mais la le type est une structure donc on pouvait aussi bien utilisé l'opérateur =, mais dans son cas la solution il faudrais effectivement que l'appelant (pour etre générique) fournisse la fonction de copie

Citation :

Cela me permet de ne pas appeler "realloc" (gourmand) à chaque ajout... mais m'oblige à allouer des blocs de 100 "t_element"

realloc n'implique pas forcement un deplacement de la zone allouée et faire grossir exponentielement la zone allouée ca peut etre encore plus efficace

Citation :

nommer ses types "t_qqchose" est assez recommandé - permet d'éviter plus tard de les confondre avec des variables.

ouai, ou alors faire comme de nombreuses lib, utilisés un préfixe (pour protèger ses noms) pour chaque types de namespaces (macros -> tout en maj, fonctions -> tout en min, types -> premiere lettre en maj)

Citation :

- je ne passe pas par un pointeur intermédiaire pour realloc. Etant donné que si realloc échoue, cela ne m'intéresse pas de garder ma liste puisque je ne peux pas m'en servir.

dans ce cas ca fuit, tu perds la valeur du pointeur

sinon, accessoirement faudrais penser à faire quelques free quand c'est nécéssaire

rital_5_4

Bonjour à tous,

J'ai enfin réussi à faire marcher cette fonction et le plus étrange c'est que je n'ai rien changé par rapport à hier. Je pense que mes premiers essai avaient du corrompre certaines données dans le tas suite à une fuite mémoire et qu'en redemarrant le pc ce matin ca a mieux marché enfin je ne vois que ca...

Le code :

Code :

void ajouterE(tab* t,const montype* e){
(*t).taille += 1;
montype* tmp;
tmp = (montype*)realloc((*t).element,(*t).taille* sizeof(montype));
if(tmp == NULL){
exit(5);
}
else{
(*t).element = tmp;
(*t).element[(*t).taille-1] = (*e);
}
}

Toutefois je vais tenir compte de toutes les remarques afin d'améliorer mon code .

Citation :

sinon, accessoirement faudrais penser à faire quelques free quand c'est nécéssaire

Les free sont fait pour chaque element du tableau en fin d'execution .

Encore merci à tous :jap: !

Publicité

FORUM HardWare.fr

Programmation

Probleme étrange avec realloc ...

Sujets relatifs
Probleme avec le validator du W3C	[PHP] Resolu Problème de chemin avec les "include"
[C] Problème de pointeurs et d'allocation	CSS probleme de cascading avec les a:link, a:hover...
Problème CVS - Magic Number	[VBA] [Resolu] [Thx to Epena o/ ] Probleme de couleur de cellule [...]
Probleme de codage RSS / Google	[RESOLU] problème champ floatval en SQL
[ASP]Probleme fonctionnement moteur de recherche	probleme cookies de session
Plus de sujets relatifs à : Probleme étrange avec realloc ...

Page générée en 0.181 secondes