Discussion :

[Dayan42]

Bonsoir,

je me tourne vers vous comme dernier recours, je ne sais plus quoi faire depuis 5 jours...

Avec un collègue nous avons fini de coder pour la fac un compilateur en C/Lex/Yacc pour un langage "MiniC" ressemblant au C. Le compilateur une fois fini nous avons décidé de l'améliorer, enfin bref il a très très bien marché. MAIS !

Mais depuis 5 jours, et vraiment du jour au lendemain, quasiment sans rien toucher (ou en tous cas aucun bout de code concernant l'allocation dynamique), le programme se met à segfault sur des mallocs, plus précisément, il s'agit de la fonction _int_malloc(), appelée soit via un malloc, soit par strdup().

Le pire c'est qu'il segfault au même endroit, tout le temps. En fait, on crée un arbre syntaxique du programme .MiniC de type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

typedef struct Arbre_bin { int nature; int valeur; Arbre_bin* d; Arbre_bin* g; } Arbre_bin;

On a une fonction creer_noeud qui alloue la mémoire d'un noeud, et c'est tout le temps lors du 1527e noeud alloué que le segfault se fait...

Sinon, lors d'un strdup, c'est lors du même lexème lu dans le fichier source.

make clean; make n'y font rien non plus, toujours le 1527e noeud... sachant du coup que les sources qui n'ont pas besoin de 1527 noeuds ne segfaultent pas... De plus, comme j'ai dit, le compilateur marchait bien avant même pour un fichier qui demande 1527 noeuds... (*) Vous me direz que c'est un souci de mémoire mais j'ai 6GO de RAM, puis tous les free() sont fait lors d'une bonne exécution. Mais bon, pour l'exécution d'un source par notre machine virtuelle, il faut bien créer toutes les tables de déclarations, de types et les arbres syntaxiques...

Merci de votre aide, nous sommes perdus !

(*) pour ceux que ca intéresse : les modifications apportées portent sur l'ajout de fonctions natives du C, comme sleep(), rand(), sqrt() etc...

[Obsidian]

Bonjour,

Bonsoir,

je me tourne vers vous comme dernier recours, je ne sais plus quoi faire depuis 5 jours...

Avec un collègue nous avons fini de coder pour la fac un compilateur en C/Lex/Yacc pour un langage "MiniC" ressemblant au C. Le compilateur une fois fini nous avons décidé de l'améliorer, enfin bref il a très très bien marché. MAIS !

Mais depuis 5 jours, et vraiment du jour au lendemain, quasiment sans rien toucher (ou en tous cas aucun bout de code concernant l'allocation dynamique), le programme se met à segfault sur des mallocs, plus précisément, il s'agit de la fonction _int_malloc(), appelée soit via un malloc, soit par strdup().

Montre-nous ton code (encadré par les balises [CODE] et [/CODE]). On ne peut rien déduire sans le lire.

Le pire c'est qu'il segfault au même endroit, tout le temps. En fait, on crée un arbre syntaxique du programme .MiniC de type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

typedef struct Arbre_bin { int nature; int valeur; Arbre_bin* d; Arbre_bin* g; } Arbre_bin;

Ça, c'est plutôt une bonne nouvelle en fait. Ça va rendre le bug beaucoup plus facile à localiser.

On a une fonction creer_noeud qui alloue la mémoire d'un noeud, et c'est tout le temps lors du 1527e noeud alloué que le segfault se fait...

Il est extrêmement probable qu'il s'agisse d'un bug latent : ton programme devait naturellement être incorrect à la base (dépassement de tableau, pointeur non vérifié, etc.) mais ne plantait jamais parce que les données manipulées à l'exécution restaient toujours dans le domaine de l'acceptable.

Sinon, lors d'un strdup, c'est lors du même lexème lu dans le fichier source.

make clean; make n'y font rien non plus, toujours le 1527e noeud... sachant du coup que les sources qui n'ont pas besoin de 1527 noeuds ne segfaultent pas... De plus, comme j'ai dit, le compilateur marchait bien avant même pour un fichier qui demande 1527 noeuds... (*) Vous me direz que c'est un souci de mémoire mais j'ai 6GO de RAM, puis tous les free() sont fait lors d'une bonne exécution. Mais bon, pour l'exécution d'un source par notre machine virtuelle, il faut bien créer toutes les tables de déclarations, de types et les arbres syntaxiques...

Encore une fois, cela va dépendre à la fois de l'approche que vous avez adoptée pour concevoir votre programme que de la manière dont vous l'avez implémentée ensuite. Il est possible, par exemple, que certains nœuds qui sont censés être libérés ne le soient pas en pratique. Il est aussi tout-à-fait possible que vous ayez décidé de charger tout l'arbre en une seule fois, ce qui devient très lourd pour les gros fichiers, et que ce chargement se fasse dans un espace qui vous paraissait largement assez grand au départ et qui a fini par ne plus l'être au fur et à mesure que les fichiers à traiter se sont complexifiés.

Montre-nous ton code.