fonctions HeapMachin - Page 1

Je me demande comment marche le tas sur TI.

1. si je déréférence un handle que je viens de libérer, qu'est ce qui se passe?

HANDLE h=HeapAlloc(tutu);
void *a;
a=HeapDeref(h);
((int*)a)[0]=0x42;
HeapFree(h);
printf("%d",*((int*)a));

1bis: si je déréférence un handle qui n'a jamais été alloué, qu'est ce qui se passe?

2. Il fait quoi, le gc? déplacement des blocs pour qu'ils soient contigus? Que se passe t il si un block est locké? on essaye de remplir les gaps avec des blocs qui pourraient rentrer?

1. C'est mal d'utiliser de la mémoire après la libération, mais je ne crois pas que ça plante.
1bis. Tu récupères ce qu'il y a dans la heap table au numéro de ce handle, c'est à dire NULL.
2. Si un bloc est locké, il n'est pas déplacé par le GC. Mais à part ça, je n'ai jamais regardé ce que font exactement HeapAlloc et HeapAllocHigh (même si je sais que cette dernière fait HeapCompress() pour commencer).

oki

1>je sais que caymal, mais pour fabriquer un allocateur, faut bien savoir ce qui se passe

ah oui en fait tu m'as rappelé que la table et le nb de handles sont fixes sous ams.

dans mon allocateur ce sera pas le cas. donc on peut pas trop comparer en fait

Lionel Debroux (./2) :
1. C'est mal d'utiliser de la mémoire après la libération, mais je ne crois pas que ça plante.

Probablement pas s'il n'y a pas eu de heap compression depuis, mais ce n'est pas un comportement garanti, ça!

1bis. Tu récupères ce qu'il y a dans la heap table au numéro de ce handle, c'est à dire NULL.

Et c'est -1 -> address error.

oki

est ce que je peux tenir pour sûr que sizeof(void)=1 quand je fais de l'arithmétique de pointeurs void*, ou vaut il mieux que j'utilise un char*?

sizeof(void)==1 est une extension GNU documentée. Pour TIGCC, c'est donc parfaitement sûr (je ne sais pas pour GTC et TIFS), en revanche si tu veux du code portable pour d'autres compilateurs, vaut mieux éviter.

C'est mal d'utiliser de la mémoire après la libération, mais je ne crois pas que ça plante.

Probablement pas s'il n'y a pas eu de heap compression depuis, mais ce n'est pas un comportement garanti, ça!

Dans le cas général, évidemment. Mais dans l'exemple qu'il donne, sauf bizarrerie (par exemple, une allocation dans un handler d'interruption qui déclencherait par malheur une heap compression), où il utilise la mémoire qu'il a libérée à l'instruction précédente, ça ne plante pas

sizeof(void)==1

squalyl (./1) :
Je me demande comment marche le tas sur TI.

Regarde heap.asm de PedroM. C'est comparable à ce que fait AMS (en plus simple et plus rapide).

squalyl (./3) :
ah oui en fait tu m'as rappelé que la table et le nb de handles sont fixes sous ams.

je crois que le nombre d'handle peut augmenter sous AMS sous certaines conditions, mais je n'ai jamais réussi à le voir marcher.

PpHd (./8) :
Regarde heap.asm de PedroM. C'est comparable à ce que fait AMS (en plus simple et plus rapide).

Mais pas compatible à 100%!

Kevin Kofler (./9) :

Mais pas compatible à 100%!

Les points où c'est différent sont commentés.

ok pour void*

il fait quoi différemment? (ok)

si, c'est même HeapMachin(truc,bidule,chose) avec

#define TRUC_ALLOC 1
#define TRUC_REALLOC 2
#define TRUC_DEREF 3
.....


( y'en a qui y ont pensé avant moi: http://pgl.yoyo.org/luai/i/lua_gc )

mode CDG:

extrait d'un tpr que j'ai positionné correctement pour avoir des chemins relatifs:

[File Editing]
Open File=C:\Documents and Settings\squalyl\Mes documents\squalyl\ucvm\trunk\vm\include\jtypes.h
[Included Files]
C File 1=src\vm\jstring.c
C File 1 Folder=vm

heuuuuu

J'ai pas regardé le code des IDE, mais tous les TPR que je connais ont des chemins absolus pour "Open File"...
C'est pas rare que j'édite les TPR avec un éditeur de texte, pas avec KTIGCC.

C'est vraiment dommage que KTigcc ne marche pas encore sous Qt/Win32, sinon je me ferais un plaisir d'implémenter ce qui m'agace.

Open File est toujours absolu, aussi sous KTIGCC, ça n'a aucune importance, si tu déplaces le projet, tout ce que ça fait est qu'il n'y aura pas de fichier ouvert, pas d'erreur.

Et ça ne peut pas être source d'erreur ? Imagine qu'on copie/colle le répertoire du projet, en ouvrant le tp copié celà va-t-il ouvrir l'ancien ?

Non, il n'ouvre pas le fichier s'il ne fait pas partie du projet.

C'est vraiment pas génial comme fonctionnement...

Lionel Debroux (./2) :
1. C'est mal d'utiliser de la mémoire après la libération, mais je ne crois pas que ça plante.

S'il n'y a pas eu de HeapCompress, ça ne plante pas, et le bloc mémoire est presque inchangé. Seuls les deux ou quatre premiers octets sont changés afin d'indiquer l'emplacement du prochain bloc occupé (mais je ne sais plus si c'est la taille libre ou l'adresse occupée qui est donnée)

en effet c'est bizarre mais honnêtement ça casse rien.

20: ah, il met des marqueurs dans la zone de données? genre on peut corrompre tout le tas en faisant des débordements?

Martial Demolins (./24) :

Flanker (./21) :
Seuls les deux ou quatre premiers octets sont changés afin d'indiquer l'emplacement du prochain bloc occupé

Ca sert à quoi pour AMS ? Ca veut dire qu'il se sert lui-même des blocs libérés ? A quoi sert la table des handles dans ce cas ?

Ça fait longtemps que je n'ai pas touché à ça, mais je suppose que c'est pour parcourir rapidement la mémoire à la recherche d'un bloc libre de la bonne taille quand il alloue ^^

handles => garder un handle fixe quand le bloc réel est déplacé.

c'est vrai, j'ai implémenté mon truc, et j'ai besoin d'une fonction bloc_suivant() qui m'oblige à scanner la table des handles.

avec un truc comme ça, t'as pas besoin de scanner la liste.

(cross, oui c'est sans doute ça)

squalyl (./23) :
20: ah, il met des marqueurs dans la zone de données? genre on peut corrompre tout le tas en faisant des débordements?

Vi, ça doit être ça.. fais des essais avec un éditeur hexa, ça sera sûrement le plus simple

#flemme# mais ok ce sera le meilleur moyen

Kevin Kofler (./6) :
sizeof(void)==1 est une extension GNU documentée. Pour TIGCC, c'est donc parfaitement sûr (je ne sais pas pour GTC et TIFS)

(GTC oui, TIFS ça m'étonnerait)