Question bete - Page 1

C'est peut etre une question bete mais ca m'intrigue alors je vais la poser.
J'ai codé un prog en C qui fais de l'alocation mémoire et qui créer des fichier tios.

Je reset ma calto et je regarde ma memoire : mémoire systeme utilisé : 65086*

Je lance mon programme et je regarde de nouveau la mémoire : mémoire systeme utilisé : 66101

Je relance encore mon prog et je regarde de nouveau la mémoire : mémoire systeme utilisé : 67083

Et c'est continuel ca ne fait que augmenter comment ca se fait ???
[edit]Edité par Shinjuku2 le 23-02-2002 à 21:10:57[/edit]

Il faut libérer toute la mémoire allouée par ton programme à la fin de celui-ci.

Je l'ai fait. Enfin j'ai fais un free(buffer) et j'ai fermer le fichier avec fclose(file).

Il faut encore liberer la memoire avec une autre commande ?

À priori non.

Question peut-être bête, mais bon: As-tu pensé à effacer l'historique de l'écran HOME ([F1][8])?

Rien à voir avec le topic : tu tiens le coup à Epitech ??

c comment epitech? vous faites koi?

ca doit etre de la glande généralisée

"le premier qui bosse a perdu !"

oui j'ai tous effacé l'ecran home avant de récupérer les valeurs.
Je coyais que cette diminusion de memoire etait normal mais apres quelque teste sur d'autres prog la perte de memoire est nul.

Donc ca viens de mon prog et je vois pas du tout pourkoi ???

PS : oui ca ce passe bien à l'epitech

g un pote qui a tenu 1 semaine à Epitech cette année Maintenant, il est en MIAS avec moi

Il m'a sorti qu'il commençait à 8h et qu'il finissait à 23h à cause des devoirs, tous les jours, même le samedi !!!
Il m'a même dit qu'au début de l'année, il y avait eu 3 mecs qui avaient été à l'hopital parce qu'ils étaient tombé dans le comma, parce que ça faisait 3 jours qu'ils dormaient pas

Par contre, g un autre pote qui est à Epita, et il s'en sort pas mal (je rappelle que Epita > Epitech )
[edit]Edité par DropF le 21-02-2002 à 20:50:19[/edit]

hmmm j'ai dormi 13h la premiere semaine alors je pense pas que ce soit la glande non
y'en a qui ont glander ben c'est eu qui ont perdu.
Generalement quand tu donnes 40 000 balles pour apprendre tu glandes pas.

Enfin....

>c comment epitech? vous faites koi?
on code en C et on code en C aussi a oui j'ai oublie on code en C.
Sinon des fois pour changer on code en C....

coder en C... le rêve !!!

>coder en C... le rêve !!!

a epitech tu fais que ca... mais vraiment que ca...

lol en ecole d'ingé d'info le C y doit y avoir pour 4heures de cours et c'est tout
(pour les TD/TP par contre je sais pas)

je me demande comment vous pouvez travailler plus que moi en prépa ?
[edit]Edité par NoRbErT le 22-02-2002 à 00:36:18[/edit]

tain c pas possible de bosser + ke moi en mias

c ou la on fe le + prog

si tu veux faire une overdose de programmation, va à Epita (si t'es très fort) ou Epitech (si t'es moins fort )

Au passage, ce sont 2 écoles qui sont "liées".
Elles se trouvent au Kremlin-Bicêtre (Région parisienne), et faut casquer : 40000F par an.

Shinjuku2 : Ton problème de mémoire ne vient pas de toi mais de la bibliothèque de TIGCC (elle comporte quelques erreurs encore), et précisément de la fonction fclose.

Kevin : je suis étonné que tu n'ai pas vu ça tout de suite, en constatant que la perte est de ~1000 octets

Remarquez, c'est valable uniquement si Shinjuku2 ouvre le fichier en écriture, et j'émet l'hypothèse avec réserves, parceque théoriquement on ne devrait perdre 1000 octets qu'au premier lancement seulement

ba de toutes façons tigcclib est dépassée. place aux jeunes : azurLib poowweeerrrr !!!!!

>Thibaut: Shinjuku2 : Ton problème de mémoire ne vient pas de toi mais de la bibliothèque de TIGCC (elle comporte quelques erreurs encore), et précisément de la fonction fclose.

Cette erreur est corrigée dans TIGCC 0.93!
Et les versions dépassées de TIGCC ne sont plus "supported" (du moins pas par moi), désolé.

D'ailleurs, Greg Dietsche, l'auteur de la correction de fclose a aussi amélioré fopen: il n'essaie plus d'écraser un fichier archivé (ce qui pouvait entraîner des plantages), mais renvoie NULL si on veut ouvrir un fichier archivé en écriture. (Ça, Thibaut, tes routines ne le font pas, n'est-ce pas?)


Et pour finir, je ne pense pas que fclose soit l'origine du problème de Shinjuku2, parce que les octets utilisés en trop se retrouveraient sous le type du fichier, pas sous "System", et parce que son premier leak est un peu plus de 1000 octets alors que l'erreur de l'ancien fclose donnerait un leak d'un peu moins de 1000 octets.
[edit]Edité par Kevin Kofler le 23-02-2002 à 16:04:54[/edit]

Nan ma fonction fopen ne le fait pas, mais elle va le faire Et puis elle est beaucoup moins grosse que la votre

Bon, j'ai échangé quelques mails avec Shinjuku2, et on a résolu le problème: tu avais raison, Thibaut, c'etait bien le bogue de l'ancien fclose. Avec la version la plus récente de TIGCC, le problème ne se produit plus.

arf...

Mais on n'a pas eu besoin des routines de l'Azur.

Oui, je sais, elles sont plus optimisées etc., mais on a plein d'autres trucs à corriger dans TIGCC en ce moment, et donc on n'a pas le temps de changer et tester des routines importantes comme fopen en ce moment. Et puis les routines qui traffiquent un octet quelconque en le sauvegardant et le restaurant après, on n'en veut pas. Déjà, j'ai dû corriger enter_ghost_space qui travaillait comme ça et pouvait causer des plantages, alors on n'a pas envie d'avoir de nouveau des histoires comme ça. Et tu dois déjà en avoir eu vu que tu as rajouté ton .word 0 à la fin de certaines routines... Et puis le nom du symbole pourrait être en ROM.

l'essentiel est que ça marche comme ça...
après, il sera temps de penser à optimiser encore