Corruption de variables sous GCC

[Gofromiel]

Gofromiel

#4373

Ben décidément, GCC produit du code bien mystérieux. Une fonction de Feelin permet d’obtenir un pointeur vers l’attribut d’une classe, correspondant à une chaine de caractères. En bonus, on peut obtenir un pointeur vers la classe qui définissant l’attribut.

FClassAttribute *F_DynamicFindAttribute(STRPTR AttributeName, FClass *FromClass, FClass **RealClass);

Le code suivant pose problème:

for (attribute = (FXMLAttribute *) Markup->AttributesList.Head ; attribute ; attribute = attribute->Next)

{

FClass *ca_class = NULL;

FClassAttribute *ca;

IFEELIN F_Log

(

FV_LOG_USER, "attribute (0x%08lx) atom (0x%08lx)(%s)(%ld) - &ca_class (0x%08lx)",

attribute, attribute->Atom, attribute->Atom->Key, attribute->Atom->KeyLength, &ca_class

);

ca = IFEELIN F_DynamicFindAttribute(attribute->Atom->Key, cl, &ca_class);

}

En effet, la variable « attribute » est corrompue après l’appel à la fonction. Cette corruption ne se produit qu’avec GCC. Le problème vient bien de « &ca_class », car si je passe NULL à la place, tout va bien.

Des idées ?? (Henes ?)

[Fab1]

Fab1

#75868

Vu comme ça difficile à dire, il faudrait voir le code de la fonction F_DynamicFindAttribute.

[Gofromiel]

Gofromiel

#75869

Après quelques tests, on dirait bien qu’il y a une problème avec l’adresse de la variable, la fonction F_DynamicFindAttribute() reçoit n’importe quoi si j’utilise l’adresse d’une variable, par contre tout va très bien lorsque j’utilise une valeur fixe e.g. NULL ou 0xABBA.

07-Jan-31 02:02:34 [XMLApplication] XMLApplication{105D804C}.New> call(0x103D3B6C, 0x105D99E4, 0x106BA248)

07-Jan-31 02:02:34 [XMLApplication] XMLApplication{105D804C}.New> F_DynamicFindAttribute(0x103D3B6C, 0x105D99E4, 0x105F00D0)

07-Jan-31 02:02:34 [XMLApplication] XMLApplication{105D804C}.New> call(0x103D2C08, 0x105D99E4, 0x106BA248)

07-Jan-31 02:02:34 [XMLApplication] XMLApplication{105D804C}.New> F_DynamicFindAttribute(0x103D2C08, 0x105D99E4, 0x105D9BD8)

07-Jan-31 02:02:34 [XMLApplication] XMLApplication{105D804C}.New> F_DynamicFindAttribute() (0x103D2C08)(=+¤=,Ð=)L=) not found

07-Jan-31 02:02:34 [XMLApplication] XMLApplication{105D804C}.New> call(0x105D9C3C, 0x105D99E4, 0x106BA248)

07-Jan-31 02:02:34 [XMLApplication] XMLApplication{105D804C}.New> F_DynamicFindAttribute(0x105D9C3C, 0x105D99E4, 0x105D9C3C)

07-Jan-31 02:02:34 [XMLApplication] XMLApplication{105D804C}.New> F_DynamicFindAttribute() (0x105D9C3C)(]œ ]›Ø]›Ø=:0) not found

07-Jan-31 02:02:34 [XMLApplication] XMLApplication{105D804C}.New> call(0x105D9CA0, 0x105D99E4, 0x106BA248)

07-Jan-31 02:02:34 [XMLApplication] XMLApplication{105D804C}.New> F_DynamicFindAttribute(0x105D9CA0, 0x105D99E4, 0x105D9CA0)

07-Jan-31 02:02:34 [XMLApplication] XMLApplication{105D804C}.New> F_DynamicFindAttribute() (0x105D9CA0)(]™ä]œ<]œ<=) not found

07-Jan-31 02:02:34 [XMLApplication] XMLApplication{105D804C}.New> call(0x105D99E4, 0x105D99E4, 0x106BA248)

07-Jan-31 02:02:34 [XMLApplication] XMLApplication{105D804C}.New> F_DynamicFindAttribute(0x105D99E4, 0x105D99E4, 0x105D99E4)

C’est vraiment à se mettre la tête dans un mur ! De toute évidence GCC déplace la variable dans le stack, du coup son adresse est erronée. Un bug du compilateur ? Peut-être existe t’il un mot clé à placer avant la déclaration de la variable pour éviter ce genre de conneries ?

[Gofromiel]

Gofromiel

#75870

C’est bien ça, en mettant la variable en « static » ça marche. Par contre c’est complètement nul dans le genre « thread safe ». C’est drôle, il va falloir que j’alloue 4 octets pour ça ??

[henes]

henes

#75871

Quelle variable ? Allouée comment ? Où ?

Attention tu va te faire modérer ™ pour cassage de forum.

[Fab1]

Fab1

#75872

Meuh,

on connait pas toutes les conditions, dur à diagnostiquer, mais je vois pas de problème dans ce bout de code en tous cas. La preuve :

http://fabportnawak.free.fr/gofro.c marche parfaitement avec GCC et suit à peu près la même « logique ».

[Alex]

Alex

#75873

@Gofro

Difficile à dire sans voir le code complet, mais moi je pencherais pour deux choses :

1) problème de pile : trop ou pas assez de paramètres à un printf (ou tout autre fonction C avec nombre d’attribut variable, je profite d’ailleurs de l’occasion pour rappeler à tous les « ceuce »qui redéveloppent leurs propres fonctions printf/vprinf (i.e. avec un paramètre définissant le format (et du coup le nombre et type des paramètres) que GCC dispose depuis pas mal de versions déjà de l’attribut format qui peut aider pas mal à débusquer ce genre de chose)

2) problème d’optimisation notamment optimisation de la boucle for, tente de déplacer la déclaration de ta variable ca_class pour voir.

Sinon faudrait savoir :

– version de GCC,

– options de compilation,

– système cible.

[Gofromiel]

Gofromiel

#75874

Alors, j’utilise l’adresse de la variable « ca_class » pour recueillir le pointeur vers la classe définissant l’attribut (FClass **). Il n’y a pas de problème lorsque j’utilise une valeur fixe, une variable statique ou l’adresse d’un bloc mémoire. Il y a bien un truc infect et mystérieux qui corrompt la pile, et ce n’est pas la fonction qui est appelée, puisqu’elle ne reçoit *même pas* la bonne adresse, si je passe celle de la variable « ca_class ».

Comme vous pouvez le voir sur le second log, le 3ème paramètre d’appel (l’adresse de la variable) « call() », n’est pas le même que celui reçu par la fonction « F_DynamicFindAttribute() ». Comble de tout, il est même différent à chaque réception !! Alors que cela ne se produit pas pour une valeur fixe, une variable statique ou une adresse mémoire !!

Evidement, que je place la variable « ca_class » en dehors de la boucle n’a aucune importance.

Pour information : j’utilise GCC 3.3, avec les options de compilation « -O2 -Wall -noixemul » et le système cible est m68k/OS3.

[henes]

henes

#75875

Enleve le -02 et réessaye.

[Fab1]

Fab1

#75876

Et essaie le 2.95.3 aussi, on sait jamais. Ce gcc3.3 68k est-il vraiment testé ?.

[Gofromiel]

Gofromiel

#75877

@Henes: A ben ça marche sans « -O2″… trop d’optimisation tue l’optimisation ?? C’est un peu con Comment faire…?

@Fab1: GCC3.3 vient avec mon CubicIDE, je pense qu’il n’y a pas de problème de ce côté là… si ?

[henes]

henes

#75878

Comment faire ?

Tout simplement utiliser un compilateur qui fonctionne et oublier les abrutis qui écrivent « haha mais que tu es bête avec ton vieux compilateur tout pourri alors que moi j’utilise gcc5 qui rules sa maman ».

Alternativement : continuer d’utiliser un gcc bugué et réécrire ton code différement pour ne pas tomber sur ce bug précis…

Parfois rajouter une variable bidon ou un appel à une fonction vide suffit.

Si tu as le temps, regarde l’assembleur généré que l’on rigole un petit peu.

[Gofromiel]

Gofromiel

#75879

Merci Henes, vous êtes superbes ! A bientôt pour un « dump » ASM.