Bonjour,
Dans un jeu que j'ai fait, j'ai écrit cette fonction pour afficher l'image de titre, stockée dans un fichier comme décrit dans un tutorial de benjamin.9xz
Seulement, quand je veux libérer la mémoire allouée, j'ai le droit à un superbe ADRESS ERROR de la TI89 (HW1 & 2)
Si je ne la libère pas, ça marche mais :
1) ce n'est pas propre
2) je ne suis sûr que la TI le fera toute seule
Pourriez-vous me dire d'où ça vient?
Voici la fonction :
int startscreen(void)
{
FILE *fp;
unsigned char *imgplane0,*imgplane1,*name; // For pictures and name
unsigned char *plane0,*plane1; // For planes
register int i;
int retval=-1;
// Allocate memory pictures and name
imgplane0 = malloc(2000);
imgplane1 = malloc(2000);
name = malloc(20);
// Test if memory allocation has succeed
if (imgplane0 && imgplane1 && name)
{
// Open graph file
fp = fopen("snakepic","rb")
if (fp != NULL)
{
// Get pictures and name
fread(imgplane0,1,2000,fp);
fread(imgplane1,1,2000,fp);
fgets(name,20,fp);
fclose(fp);
// Set up screen
ClrScr(); GrayOn();
plane0 = GetPlane(0);
plane1 = GetPlane(1);
// Copy picture on the screen (100 lines, 20 char lenth)
for(i=0;i<100;i++,plane0+=30,plane1+=30,imgplane0+=20,imgplane1+=20)
{
memcpy(plane0,imgplane0,20);
memcpy(plane1,imgplane1,20);
}
while (ngetchx() != KEY_ENTER) ;
GrayOff(); // Turn gray levels off
// Free memory allocated (BUG)
retval = 0;
free(imgplane0);
free(imgplane1);
free(name);
}
}
return retval;
}
Merci à vous
[edit]Edité par vanilius le 17-11-2001 à 18:51:59[/edit]
[edit]Edité par vanilius le 17-11-2001 à 18:55:49[/edit]
C'est bizarre... ça plante sur laquelle des trois lignes ?
Un truc, par contre: tu pourrais mettre un alloca pour name, et ne pas le libérer à la fin car c'est fait automatiquement.
En fait, ça plante à la 2eme
Le premier plan disparaît de l'écran puis c'est le bug
Que veux-tu dire par mettre un alloca?
c'est normal:
cree 2 pointeurs vers imgplane0 et 1
puis utilise les dans ton programme:
lça bugge car tu modifie les adresses des pointeurs (+=20) et donc free tombe sur
une adresse sur laquelle il ne n'a pas la priorité: erruer d'adresse
tu ne modifie pas name donc free marchera
pour savoir ou ça plante, mets des printf("ninstructuon ** passée") entre les instructions

fabetal_ > Hier, je me suis fait monter par un pote
redangel > et en chevals, ça donne quoi?
Nil> OMG I think I'm gay
Ah oui ... fuite mémoire ... J'aurais dû y penser
Je te remercie
farib Le 17/11/2001 à 21:42 tu commentes tes progs en anglais ???
Oui je code et je commente en anglais en général
Je trouve que c'est plus court pour les noms de variables et de fonctions et c'est aussi par habitude de coder des projets sous licence GNU
[edit]Edité par vanilius le 17-11-2001 à 21:55:50[/edit]
farib Le 17/11/2001 à 23:23 il manquerait pas un "s" a tous tes verbes ?
PpHd Le 19/11/2001 à 19:24 Un autre bug : tu ne dois pas faire de tests groupes du malloc et les 3 free derreire.
Si l'un d'eux merde, il plantera car un free(NULL) entraine un crash.
sinon, avant de faire les malloc, tu teste si tu as assez de mem pour allouer les 3...
=> dans 99% des cas, ça suffit...
et aussi, pour gagner de la place,
tu fais un seul aloc au debut du prog,
puis tu fais pointer des varz vers une partie de la zone que tu t'es reservé...
c'est aussi une bonne maniere pour ne pas creer d'===adress error===(mais il faut quand meme verifier si tu ecris dans la memoire voulue
sinon, c'est du code sale)

fabetal_ > Hier, je me suis fait monter par un pote
redangel > et en chevals, ça donne quoi?
Nil> OMG I think I'm gay
oui, et il faut que la zone allouée soit de taille inférieure ç sizeof(unsigned int)
(environ 64ko)
Non. Déjà sizeof(unsigned int) vaut 2, pas la valeur maximale d'un unsigned int. Puis, cette valeur maximale vaut 65535 alors que malloc est limité à 65518.
PpHd Le 20/11/2001 à 17:55 Au fait, faudrait que je fixe ce pb avec free dans PreOs.
Et c'est quoi l'intérêt par rapport à #define free(x) ({if(x) HeapFreePtr(x);}), qui marcherait aussi en _nostub ou avec d'autres kernels que PreOS? Non seulement un programmeur peut le faire tout seul (depuis quand c'est compliqué de mettre if (machin)? Même les instructions de portabilité pour les programmeurs GCC signalent qu'une implémentation de free comme celle d'AMS/TIGCCLIB est tout à fait acceptable et qu'il faut obligatoirement mettre ces ifs dans toute source faisant partie de GCC lui-même pour en tenir compte.), mais si on veut le faire pour lui, c'est dans TIGCCLIB qu'il faut mettre ce genre de choses , pas dans PreOS -> parler à Sebastian Reichelt et Zeljko Juric.
PpHd Le 21/11/2001 à 16:07 NON ! Ca devrait etre AMS qui devrait se premunir contre ce genre de bugs a la con !
D'accord PpHd, AMS devrait le faire. Mais puisque ça ne le fait pas, il faut recourir à des subterfuges comme celui que propose Kevin.