Forum de Ti-Gen.org, le site francophone des TI

Bienvenue Invité ! Se connecter Mes sujets	Administrer
Utilisateurs actifs : Aucun membre + 1 visiteur

Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.

:: Index » Forum Ti68K » Programmation C » Méthode de gestion des mallocs (32 réponse(s))

./POST DE DEPART (post n°0) Marquer comme non lu.

LionelA

Ecrit le: Samedi 5 mars 2005 à 15:07

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 947

Membre n°206

Inscrit le 19 avril 2004

Voilà donc pour ceux qui ont plein de malloc dans leurs programmes et qui ont eu la flemme de les tester et après de faire une gestion des erreurs pour liberer toute la mémoire, un .c et un .h qui permettent de s'en sortir

le fichier mem.h :

// Header File
// Created 02/01/2005; 20:11:47
#ifndef MEM_H
#define MEM_H

// Memory Management
#define DEV_PHASE 0 // 0: not in development phase, 1: get message if there is not enough *_MAX_*
#define INTERRUPT_MAX_HANDLERS 5
#define MEMORY_MAX_HANDLES 32
#define MEMORY_MSG "Mon message pour dire qu'il y a pas assez de ram"

#include <tigcclib.h>

__attribute__((noreturn)) void Exit (void);
void *Malloc (unsigned long Size);
void *Calloc (unsigned short NoOfItems, unsigned short SizeOfItems);
void Free (void *Ptr);

INT_HANDLER SetIntVector(long IntVec, INT_HANDLER Handler);
void ReSetIntVector(long IntVec);

#endif

et le fichier mem.c (attention : code illisible)

// C Source File
// Created 02/01/2005; 23:14:39

#include "mem.h"

#if DEV_PHASE == 1
unsigned char overptr = 0;
unsigned char overint = 0;
#endif

INT_HANDLER hdlrs[INTERRUPT_MAX_HANDLERS*2];
void *ptrs[MEMORY_MAX_HANDLES];
unsigned short nbptr = 0;
unsigned short nbhdlr = 0;

__attribute__((noreturn)) void Exit (void) {
  void ** ptr = ptrs + nbptr;
  for(; (ptr--) != ptrs; free(*ptr));
  GrayOff (); // Does nothing if not On
  INT_HANDLER* hdlr = hdlrs + 2*nbhdlr;
  for(; hdlr != hdlrs; hdlr-=2 ,SetIntVec ((long)(*hdlr), *(hdlr+1)));
  clrscr ();
#if DEV_PHASE == 1
  if(overptr) {
    DlgMessage("DEVELOPMENT","Not enough MEMORY_MAX_HANDLES",BT_OK,BT_NONE);
    overptr = 0;
  }
  else if(overint) {
    DlgMessage("DEVELOPMENT","Not enough INTERRUPT_MAX_HANDLERS",BT_OK,BT_NONE);
    overint = 0;
  }
  else
#endif
  DlgMessage("MEMORY",MEMORY_MSG,BT_OK,BT_NONE);
  nbptr=0;
  nbhdlr = 0;
  exit (0);
}

void *Malloc (unsigned long Size) {
#if DEV_PHASE == 1
  if(nbptr == MEMORY_MAX_HANDLES) overptr = 1, Exit ();
#endif
  void ** ptr = ptrs + (nbptr++);
  if ((*ptr = malloc(Size)))
    return *ptr;
  nbptr--;
  Exit ();
}

void *Calloc (unsigned short NoOfItems, unsigned short SizeOfItems) {
#if DEV_PHASE == 1
  if(nbptr == MEMORY_MAX_HANDLES) overptr = 1, Exit ();
#endif
  void ** ptr = ptrs + (nbptr++);
  if ((*ptr = calloc(NoOfItems, SizeOfItems)))
    return *ptr;
  nbptr--;
  Exit ();
}

void Free (void *Ptr) {
  void ** ptr = ptrs + nbptr - 1;
  unsigned char i = 0;
  for(; *ptr != Ptr; ptr--, i++);
  free(Ptr);
  memmove (ptr, ptr+1, i * sizeof(void *));
  nbptr--;
}

INT_HANDLER SetIntVector(long IntVec, INT_HANDLER Handler) {
#if DEV_PHASE == 1
  if(nbhdlr == INTERRUPT_MAX_HANDLERS) overint = 1, Exit ();
#endif
  INT_HANDLER* hdlr = hdlrs + 2*(nbhdlr++);
  *(hdlr++) = (INT_HANDLER)IntVec;
  *hdlr = GetIntVec (IntVec);
  SetIntVec (IntVec, Handler);
  return (*hdlr);
}

void ReSetIntVector(long IntVec) {
  INT_HANDLER* hdlr = hdlrs + 2*(nbhdlr - 1);
  unsigned char i = 0;
  for(; (long)(*hdlr) != IntVec; hdlr-=2, i++);
  SetIntVec (IntVec, *(hdlr+1));
  memmove (hdlr, hdlr+2, i * sizeof(INT_HANDLER)*2);
  nbhdlr--;
}

Ce code gère l'allocation par des fonctions Malloc ou Calloc (vous devez remplacer vos malloc et calloc avec)
la liberation par la fonction Free (idem)
lors d'une erreur d'allocation le programme quitte et restaure toute la ram allouée avec ces fonctions et restaure les handlers d'interruption détournés (Il faut utiliser les fonctions fournies aussi)
Par contre vous aurez quand même des pertes mémoire si vous utilisez des fonctions comme fopen qui font leur propre allocation (donc il faut utiliser les fonction de la vat pour les fichiers ou bien rajouter une gestion des fichiers ouverts à ce module)

Voilà voilà

Je précise (avant de me faire engueuler) que cette méthode n'est à utiliser qu'en cas de flemme intense, sinon il faut pas faire comme ca (paraît-il

)

-Edité le Samedi 5 mars 2005 à 15:11 par LionelA-

Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/

./Post n°1 Marquer comme non lu.

Jfg

Ecrit le: Samedi 5 mars 2005 à 15:41

Administrateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 1260

Membre n°60

Inscrit le 23 février 2004

Quand on connais dès le début le montant de la mémoire à allouer, il vaut mieux faire une grosse allocation (et donc un seul free) et distribué la mémoire a des pointeurs différents que plusieurs petite allocations. C'est tout aussi rapide que d'utiliser le .c et .h à LionelA.
Si par contre on fait des allocations un peu partout dans le programme, le code de LionelA est utile.

Kill Mario

./Post n°2 Marquer comme non lu.

Kevin Kofler

Ecrit le: Samedi 5 mars 2005 à 16:09

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Puisqu'on en est aux systèmes de gestion de mémoire, voilà une méthode beaucoup plus propre:

1. Identifier les fonctions allocatrices. Ce sont toutes les fonctions de ce style:

void *foo(...)
{
  void *ret;
  ...
  ret = malloc(...);
  ...
  return ret;
}

c'est-à-dire les fonctions qui se comportent essentiellement comme malloc. Toutes les autres fonctions sont des fonctions non-allocatrices. En particulier, une fonction non-allocatrice est responsable de libérer tout ce qu'elle a alloué avant de retourner. Si une fonction allocatrice alloue plus que ret seulement, elle est responsable de libérer tout ce qu'elle a alloué à part ret (et à part possiblement des sous-structures de ret qui peuvent être libérées en connaissant ret - je fais une description simplifiée ici).

2. Utiliser les exceptions. On remplace partout malloc par malloc_throw. Notre fonction allocatrice ressemble donc maintenant à:

void *foo(...)
{
  void *ret;
  ...
  ret = malloc_throw(...);
  ...
  return ret;
}

et se comporte donc comme malloc_throw. Comme il n'y a plus de différences entre une fonction allocatrice et malloc_throw pour ce qui suit, je noterai alloc_throw pour toute fonction allocatrice ou malloc_throw. La fonction exacte a peu d'importance par la suite.

3. En cas d'exception provoquée par une fonction d'allocation, tout ce qui a précédemment été alloué dans la même fonction doit être libéré. Les blocs TRY...FINALLY...ENDFINAL sont idéaux pour ça. Une fonction non-allocatrice ressemblera donc à:

void bar(void)
{
  void *p1=alloc_throw(...);
  TRY
    void *p2=alloc_throw(...);
    TRY
      void *p3=alloc_throw(...);
      TRY
        ...
      FINALLY
        free(p3);
      ENDFINAL
    FINALLY
      free(p2);
    ENDFINAL
  FINALLY
    free(p1);
  ENDFINAL
}

Attention à utiliser la bonne fonction free pour la fonction d'allocation utilisée, par exemple: malloc_throw -> free, HeapAllocThrow -> HeapFree, GrayOnThrow -> GrayOff. Attention aussi à utiliser toujours la variante "throw" des fonctions d'allocation de TIGCCLIB.

4. Activer l'option ENABLE_ERROR_RETURN ("Allow returning errors to AMS" dans les Program Options), pour que l'erreur "Memory" soit passée à AMS.

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!

./Post n°3 Marquer comme non lu.

LionelA

Ecrit le: Samedi 5 mars 2005 à 17:32

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 947

Membre n°206

Inscrit le 19 avril 2004

Ok mais comment faire dans le cas où tu as des fonctions du genre :

char * ptr1;
char * ptr2;

void init(void) {
...
ptr1 = (char*)malloc(...);
ptr2 = (char*)malloc(...);
...
}

void end(void) {
free(ptr1);
free(ptr2);
}

(j'ai à peu près que de ça dans Mode7Engine, tu comprend pourquoi j'ai pas voulu tout recoder

)

./Post n°4 Marquer comme non lu.

Jfg

Ecrit le: Samedi 5 mars 2005 à 17:39

Administrateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 1260

Membre n°60

Inscrit le 23 février 2004

Tu free toute la mémoire en même tps ?

Kill Mario

./Post n°5 Marquer comme non lu.

LionelA

Ecrit le: Samedi 5 mars 2005 à 17:43

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 947

Membre n°206

Inscrit le 19 avril 2004

je ne suis pas sur de capter la question

Si c'est une suggestion, ben je peux pas tout allouer dans un init et tout freer à la fin car les calculs intermediaires pour placer les waypoints sur la map prennent à fond de mémoire mais temporairement, puisque je libere tout une fois calculé.
Si c'est vraiment une question, la premiere réponse y répond aussi

./Post n°6 Marquer comme non lu.

Sasume

Ecrit le: Samedi 5 mars 2005 à 18:44

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Kevin> Ça donne quoi en ASM ton code ?

./Post n°7 Marquer comme non lu.

Kevin Kofler

Ecrit le: Samedi 5 mars 2005 à 23:00

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

LionelA :
Ok mais comment faire dans le cas où tu as des fonctions du genre :

char * ptr1;
char * ptr2;

void init(void) {
...
ptr1 = (char*)malloc(...);
ptr2 = (char*)malloc(...);
...
}

void end(void) {
free(ptr1);
free(ptr2);
}

init est ta fonction d'allocation, end est ta fonction de libération. La seule chose à laquelle faire attention est la sémantique "tout ou rien" d'une fonction d'allocation: soit tout est alloué correctement, soit une exception est jetée et rien n'est alloué. Cela donne:

void init(void) {
  ...
  ptr1 = (char*)malloc_throw(...);
  TRY
    ptr2 = (char*)malloc_throw(...);
    ...
  FINALLY
    free(ptr1);
  ENDFINAL
}

void end(void) {
  free(ptr1);
  free(ptr2);
}

void caller(void) {
  init();
  TRY
    ...
  FINALLY
    end();
  ENDFINAL
}

Et il est également à envisager de regrouper tes 2 allocations en une seule allocation, ce qui donnerait une allocation atomique et te permettrait donc de te passer du TRY...FINALLY...ENDFINAL dans init.

Cela dit, une chose qui n'est pas prévue dans cette architecture générale est l'utilisation de realloc. Pour ça, il faut réfléchir au cas par cas au comportement correct en termes de handlers d'exceptions.

./Post n°8 Marquer comme non lu.

Kevin Kofler

Ecrit le: Samedi 5 mars 2005 à 23:13

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Sasume :
Kevin> Ça donne quoi en ASM ton code ?

void bar(void)
{
  void *p1=malloc_throw(100);
  TRY
    void *p2=malloc_throw(200);
    TRY
      void *p3=malloc_throw(300);
      TRY
        ngetchx();
      FINALLY
        free(p3);
      ENDFINAL
    FINALLY
      free(p2);
    ENDFINAL
  FINALLY
    free(p1);
  ENDFINAL
}

donne:

bar:
  link.w %fp,#-180
  movm.l #0x1f20,-(%sp)
  lea malloc_throw,%a2
  move.w #100,%a0
  jbsr (%a2)
  move.l %a0,%d7
  pea -180(%fp)
  move.l 1360(%a5),%a0
  jbsr (%a0)
  move.w %d0,%d5
  addq.l #4,%sp
  jbne .L2
  move.w #200,%a0
  jbsr (%a2)
  move.l %a0,%d6
  pea -60(%fp)
  move.l 1360(%a5),%a0
  jbsr (%a0)
  move.w %d0,%d4
  addq.l #4,%sp
  jbne .L4
  move.w #300,%a0
  jbsr (%a2)
  move.l %a0,%a2
  pea -120(%fp)
  move.l 1360(%a5),%a0
  jbsr (%a0)
  move.w %d0,%d3
  addq.l #4,%sp
  jbne .L6
#APP
  .xdef __ref_all___set_file_in_use_bit
#NO_APP
  move.l 324(%a5),%a0
  jbsr (%a0)
  move.l 1364(%a5),%a0
  jbsr (%a0)
.L6:
  move.l %a2,-(%sp)
  move.l 652(%a5),%a0
  jbsr (%a0)
  addq.l #4,%sp
  tst.w %d3
  jbeq .L8
  move.w %d3,-(%sp)
  jbra .L15
.L8:
  move.l 1364(%a5),%a0
  jbsr (%a0)
.L4:
  move.l %d6,-(%sp)
  move.l 652(%a5),%a0
  jbsr (%a0)
  addq.l #4,%sp
  tst.w %d4
  jbeq .L10
  move.w %d4,-(%sp)
.L15:
  move.l 1356(%a5),%a0
  jbsr (%a0)
.L10:
  move.l 1364(%a5),%a0
  jbsr (%a0)
.L2:
  move.l %d7,-(%sp)
  move.l 652(%a5),%a0
  jbsr (%a0)
  addq.l #4,%sp
  tst.w %d5
  jbeq .L14
  move.w %d5,-(%sp)
  jbra .L15
.L14:
  movm.l -204(%fp),#0x4f8
  unlk %fp
  rts

./Post n°9 Marquer comme non lu.

LionelA

Ecrit le: Jeudi 14 juillet 2005 à 04:02

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 947

Membre n°206

Inscrit le 19 avril 2004

Voilà une mise à jour de mon système anti leak (ca en interessera certains (je pense a FpgForce

)) :
mem.h

// Header File
// Created 02/01/2005; 20:11:47
#ifndef MEM_H
#define MEM_H

#include <tigcclib.h>

// Memory Management
#define DEV_PHASE 1 // 0: not in development phase (release), 1: get message if there is not enough *_MAX_*
#define NB_EXIT_HANDLES 7 // You may want to exit the application and let the memory manager to free NB_EXIT_HANDLES handles for you
#define INTERRUPT_MAX_HANDLERS 5
#define MEMORY_MAX_HANDLES 27
#define MEMORY_MSG "There is not enough free RAM.\nYou don't need to reset your calculator, everything has been intercepted"
#ifndef SAVE_SCREEN
  extern unsigned char * scr;
  // assumes that home screen has previously been stored into a buffer pointed by global variable unsigned char * scr;
  #define ENDING_MESSAGE "My app by me"
#endif

void mem_init(void);
__attribute__((noreturn)) void Exit (unsigned char msg);
void *Malloc (unsigned long Size);
void *MallocNoExit (unsigned long Size);
void Free (void *Ptr);
HANDLE Keep (void *Ptr);

INT_HANDLER SetIntVector(long IntVec, INT_HANDLER Handler);
void ReSetIntVector(long IntVec);

#endif

mem.c

// C Source File
// Created 02/01/2005; 23:14:39

#include "mem.h"

#if DEV_PHASE == 1
unsigned char overhdl;
unsigned char overint;
#endif
#ifndef SAVE_SCREEN
unsigned char * scr;
#endif

INT_HANDLER hdlrs[INTERRUPT_MAX_HANDLERS*2];
HANDLE hdls[MEMORY_MAX_HANDLES];
unsigned short nbhdl;
unsigned short nbhdlr;

void mem_init(void) {
  nbhdl = 0;
  nbhdlr = 0;
  #if DEV_PHASE == 1
    overhdl = 0;
    overint = 0;
  #endif
}

__attribute__((noreturn)) void Exit (unsigned char msg) {
  HANDLE * hdl = hdls + nbhdl;
  for(; (hdl--) != hdls; HeapFree(*hdl));
  GrayOff ();
  INT_HANDLER* hdlr = hdlrs + 2*nbhdlr;
  for(; hdlr != hdlrs; hdlr-=2 ,SetIntVec ((long)(*hdlr), *(hdlr+1)));
  ClrScr ();
#if DEV_PHASE == 1
  char str[59];
  if(overhdl) DlgMessage("DEVELOPMENT","Not enough MEMORY_MAX_HANDLES",BT_OK,BT_NONE);
  else if(overint) DlgMessage("DEVELOPMENT","Not enough INTERRUPT_MAX_HANDLERS",BT_OK,BT_NONE);
  else if(!msg && nbhdl > NB_EXIT_HANDLES) {
    sprintf(str, "Memory Leak Detected : %u abnormally not freed Handles", nbhdl-NB_EXIT_HANDLES);
    DlgMessage("DEVELOPMENT",str,BT_OK,BT_NONE);
  }
#endif
  if(msg) DlgMessage("MEMORY",MEMORY_MSG,BT_OK,BT_NONE);
  nbhdl=0;
  nbhdlr = 0;
#ifndef SAVE_SCREEN
  LCD_restore(scr);
  ST_helpMsg(ENDING_MESSAGE);
#endif
  exit (0);
}

static inline void *MallocInternal (unsigned long Size, unsigned char exit_if_fail) {
#if DEV_PHASE == 1
  if(nbhdl == MEMORY_MAX_HANDLES) overhdl = 1, Exit (0);
#endif
  HANDLE * hdl = hdls + (nbhdl++);
  if ((*hdl = HeapAlloc(Size)))
    return HLock(*hdl);
  nbhdl--;
  if (exit_if_fail) Exit (1);
  return NULL;
}

void *Malloc (unsigned long Size) {
  return MallocInternal(Size, 1);
}

void *MallocNoExit (unsigned long Size) {
  return MallocInternal(Size, 0);
}

static inline HANDLE FreeInternal (void *Ptr, unsigned char keep) {
  HANDLE * hdl = hdls + nbhdl - 1;
  HANDLE h = H_NULL;
  unsigned char i = 0;
  for(; HeapDeref(*hdl) != Ptr; hdl--, i++);
  if(!keep) HeapFree(*hdl);
  else h = *hdl;
  memmove (hdl, hdl+1, i * sizeof(HANDLE));
  nbhdl--;
  return h;
}

void Free (void *Ptr) {
  FreeInternal(Ptr, 0);
}

HANDLE Keep (void *Ptr) {
  return FreeInternal(Ptr, 1);
}

INT_HANDLER SetIntVector(long IntVec, INT_HANDLER Handler) {
#if DEV_PHASE == 1
  if(nbhdlr == INTERRUPT_MAX_HANDLERS) overint = 1, Exit (0);
#endif
  INT_HANDLER* hdlr = hdlrs + 2*(nbhdlr++);
  *(hdlr++) = (INT_HANDLER)IntVec;
  *hdlr = GetIntVec (IntVec);
  SetIntVec (IntVec, Handler);
  return (*hdlr);
}

void ReSetIntVector(long IntVec) {
  INT_HANDLER* hdlr = hdlrs + 2*(nbhdlr - 1);
  unsigned char i = 0;
  for(; (long)(*hdlr) != IntVec; hdlr-=2, i++);
  SetIntVec (IntVec, *(hdlr+1));
  memmove (hdlr, hdlr+2, i * sizeof(INT_HANDLER)*2);
  nbhdlr--;
}

et un petit exemple d'utilisation :
main.c

// C Source File
// Created 28/06/2005; 15:06:16

#include <tigcclib.h>
#include "mem.h"

// pour tester la redirection d'auto int
INT_HANDLER OldInt;

DEFINE_INT_HANDLER(MyInt) {
  ExecuteHandler (OldInt);
}

// Main Function
void _main(void)
{
  // sauve l'ecran home sur la pile et fait pointer scr dessus pour quand on quitte le prog
#ifndef SAVE_SCREEN
  LCD_BUFFER scrdata;
  LCD_save (scrdata);
  scr = scrdata;
#endif

  mem_init(); // pour reinitialiser les variables globales de la lib

  char * ptr = Malloc(10000); // test d'allocation
  ptr[0] = 0; // (pas avoir le warning unused variable si on a commenté les lignes du bas)
  OldInt = SetIntVector (AUTO_INT_1, MyInt); // test redirection
  if(!GrayOn ()) Exit(1); // si le Grayon foire il faut appeler Exit (car l'allocation n'est pas faite avec mes fonctions)
  // le parametre de Exit doit etre 1 pour dire que ca s'est terminé par une erreur

  // tests liberation etc ...

  // si tu vire ces deux lignes ca marche encore sans leaker car le Exit s'occupe de tout virer
  // ,eteindre les niveau de gris et meme de restaurer les redirections d'auto int,
  // bref la calc revient dans son etat d'origine exactement apres un Exit
/*
  Free(ptr);
  ReSetIntVector(AUTO_INT_1);
*/
  Exit(0); // parametre 0 pour dire que ca s'est bien terminé
}

Les nouveautés sont :

Edit : j'ai oublié de dire que j'ai viré Calloc car en fait c'est un peu bidon comme fonction (par contre faudra peut etre que je mette un Realloc)

Je crois que c'est tout, si vous avez des questions/critiques/insultes/messages en #ffffff n'hesitez pas

Pour ce qui est de l'utilisation du code, comme d'hab vous en faite ce que vous voulez, vous pouvez meme l'imprimer sur du PQ et vous connaissez la suite...

Bref et si vous l'utilisez et que vous voulez mentionner mon nom (Lionel Anton) pas de pb et si voulez pas le mentionner pas de pb non plus

voila

-Edité le Jeudi 14 juillet 2005 à 04:08 par LionelA-
-Edité le Vendredi 15 juillet 2005 à 15:15 par LionelA-

./Post n°10 Marquer comme non lu.

LionelA

Ecrit le: Jeudi 14 juillet 2005 à 04:43

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 947

Membre n°206

Inscrit le 19 avril 2004

Je pense que je sortirais un article qui regroupera toutes mes techniques de prog (synchro, link, memoire) -> "The Forbidden TI Techniques"

au fait, merci pour le nom JfG

./Post n°11 Marquer comme non lu.

Folco

Ecrit le: Jeudi 14 juillet 2005 à 09:49

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Pas mal, mais implémenter tout ça dans chaque programme, ça revient pas à recréer un kernel pour chaque programme??? pas mal pour la place mémoire :/

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°12 Marquer comme non lu.

Lionel Debroux

Ecrit le: Jeudi 14 juillet 2005 à 11:58

Envoyer un message privé à Lionel Debroux

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Ce système n'est nécessaire que pour les programmes qui sont codés n'importe comment, c'est marqué depuis le début de ce topic...

Lionel Debroux - membre de TICT.

./Post n°13 Marquer comme non lu.

LionelA

Ecrit le: Jeudi 14 juillet 2005 à 15:13

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 947

Membre n°206

Inscrit le 19 avril 2004

Ben ouais evidement, je le conseille pas mais c'est très utile pour les programme qui comportent des tonnes d'allocations (en tout cas c'est mieux que de devoir se farcir de TRY partout je trouve)

./Post n°14 Marquer comme non lu.

limmt

Ecrit le: Jeudi 14 juillet 2005 à 16:45

Administrateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Groupe: Omega staff

Messages: 4712

Membre n°20

Inscrit le 01 février 2004

et les mallloc_throw ca vous dit pas?

http://www.falco-fr.com/ - http://www.jump67.com/ - http://www.msf-league.com/

./Post n°15 Marquer comme non lu.

LionelA

Ecrit le: Jeudi 14 juillet 2005 à 17:12

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 947

Membre n°206

Inscrit le 19 avril 2004

ben ca veut dire que tu fais confiance a AMS pour rattraper la merde ou bien que tu entoure tes malloc_throw par des TRY etc... (cf. les posts de Kevin) et ca ca sux si t'as des tonnes de malloc.

./Post n°16 Marquer comme non lu.

Folco

Ecrit le: Jeudi 14 juillet 2005 à 17:19

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

...
Un programme bien fait doit être capable de libérer ses allocations et de quitter sans crasher la calc en cas d'échec sur une alocation, pour moi c'est l'essentiel, après quelque soit la méthode, si ça marche, tant mieux.

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°17 Marquer comme non lu.

Link

Ecrit le: Vendredi 15 juillet 2005 à 10:02

Membre: Magister

Messages: 302

Membre n°896

Inscrit le 25 juin 2005

En fait, ce truc doit être pas mal pour débugguer...

Par contre, je ne vois pas trop ce que c'est que NB_EXIT_HANDLES ... #confus#

./Post n°18 Marquer comme non lu.

Folco

Ecrit le: Vendredi 15 juillet 2005 à 13:34

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Sans trop regarder, ça doit être la taille d'un buffer de handles non?

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°19 Marquer comme non lu.

LionelA

Ecrit le: Vendredi 15 juillet 2005 à 14:50

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 947

Membre n°206

Inscrit le 19 avril 2004

non non

En fait c'est pour detecter le nombre de handles non libérés a l'interieur du programme durant la phase de developpement.
En fait quand le main quitte on peut vouloir que ca soit normal que le Exit libere un certain nombre de handles qui sont utilisés tout au long du prog (ca evite de mettre du code pour liberer ces handles) et donc il ne faut pas qu'ils soient detectés parmi les handles anormalement non libérés.