Vérification d'un Handle - Page 1

Hello
Je voulais savoir si c'était possible de vérifier qu'un handle (unsigned short) est valide, parce que je voudrais qu'il soit possible de fournir sous forme d'argument numérique au programme (sur l'estack) un handle vers un charset, mais aucun moyen de vérifier s'il s'agit bien d'un vrai handle et pas une connerie...

if h<5 ou h>2000, pas bon.
if HeapDeref(h)==NULL, pas bon.

Merci je n'avais pas essayé h<5 || h>2000 parce que même en faisant HeapDeref(h)==NULL j'ai parfois des plantages, la calc se bloque environ une seconde (délai toujours identique ) puis m'affiche Protected memory violation. Saurais-tu d'où ça vient?

HeapDeref necessite un handle valide.

c'est pas HeapDeref qui fait le plantage, c'est que si le handle est > 2000, HeapDeref ne renverra pas NULL. Et je dirais que c'est plutôt h>0 que h>5 (même si de 0 à 5 c'est des handles système)

L'handle 0 n'existe pas.
Les handles de 1 a 4 servent a rien... Si peut etre a reserver une possible allocation memoire pour une extension de la table des handles. C'est tout.

bah si on les efface, ils servent à quelque chose, vu qu'il sont réutilisés Et la TI ne plante pas quand on les efface

Je pense que ca posera des problemes si tu as plus de 2000 handles.

Il me semble bien que le max de handles est 4096. En tous cas la TI renvoie une erreur "Memoire" si on a plus que (environ) 4090 variables.
Dans ce cas-là le TIOS crée deux tables? Parce que c'est 2000 tout rond ou 2048 la limite d'un handle valide?

C'est 2000 la limite. Mais normalement le TIOS peut en avoir plus, je ne sais pas exactement ce qui fait que ça peut foirer dans certaines conditions.

Bin il me semble surtout que le max de handle est de 2000 et que de fait on peut pas avoir plus de 2000 variables (et c'est bien 2000, et pas 2048)
Mais un petit prog me fait douter :
prgm
for i,0,5000
expr("0->str"&string(i))
disp i
endfor
endprgm

il s'arrête à 2745 avec une erreur 'Memory' et après la TI plante

2745 c'est bizarre Que te dit tthdex avant exécution? Cela dit, le répertoire avec 2745 entrées, ça prend (quand même ) 38 ko, plus 6 octets par entrée (16 ko) plus les 2000 handles supplémentaires (8 ko) -> pas plausible. Si ton répertoire a déjà pas mal d'entrées, ça peut s'expliquer par la taille du répertoire qui dépasse 64k (mais il en faudrait quand même 1000...).

Ce nombre varie avec la RAM dispo ou pas? Et si tu rajoutes une entrée dans le répertoire courant en en enlevant une dans un autre, ça change? Et si tu rajoutes une entrée dans un autre répertoire? Et si tu remplaces le 0->... par un 1->... ?

Déjà, j'utilise pas tthdex, je préfère mon shell qui qui identifie plus de handles
Je vais refaire le test en lançant le prog depuis mon shell.
j'ai pas trop suivi ton calcul : une entrée fait 14o dans la VAT et au minimum 8o dans la RAM (vu qu'un handle a une taille min de 6o). Ce qui fait en gros 22o par variable. x 2000 > 43ko dans la RAM. Je vois pas ce qui a de pas plausible.

Avant exécution :
nombre maxi de handles 2000 (220308o)
1789 handles libres (186964o libres)
plus grand handle : 65520o
début heap à 0x00A360
adresse table 0x8420
le nbr de handles en RAM, verrouillés et déplaçables n'est pas très important

Après exécution :
j'ai breaké le prog à 2300 et quelques. Le handle du répertoire a une taille de 34166o
d'abord on regarde la VAT à l'éditeur hexa, qui a l'air normale
la dernière variable (la 2364ème) a le handle 0xA16 (=2582 ! )
Pour les infos RAM, j'ai :
début heap à 0x00AC88
nombre maxi de handles : 2586 (217964o)
9 handles libres (132550o avec HeapAvail)
RAM valide (qqes secondes de calcul)
plus grand handle 65520o (après bcp de calcul, ptêt 20s)
adresse de la table = 0x008420 (elle est fixe de toute manière)
Par contre, mon programme crashe quand on va dans l'explorateur de handles, un bug à corriger...

Après une 2e exécution (sans breaker le prog)
arrêt à la 2727e variable
début heap à 0x00B254
nombre maxi de handles : 2957 (216480o)
8 handles libres (114204o avec HeapAvail)
RAM valide (qqes secondes de calcul)
plus grand handle 65520o (après bcp de calcul, ptêt 20s)
adresse de la table = 0x008420 (elle est fixe de toute manière)


tthdex donne-t-il autant d'info ?

Apparement, TI a tout prévu qu'on puisse mettre plus que 2000 handles La table des handles finit juste là où la heap commence.

Au départ c'était pas un topic de pub pour ton prog

Ah oui j'ai oublié de préciser que j'avais archivé les variables créées pour le test. Cela influe peut-être non? Enfin bon la TI est quasi inutilisable une fois que le programme a quitté avec une erreur memory, déjà >20 secondes pour réafficher l'écran HOME, le var-link on n'en parle pas, etc.

Apparement, TI a tout prévu qu'on puisse mettre plus que 2000 handles

Ca, je l'avais dit depuis longtemps. Mais je ne pensais pas qu'ils augmentaient la taille par pas de seulement 10 (ou 20) handles... Ca doit carrément ralentir, à partir de 1700, non?

Sauf que ca doit etre possible de locker un handle pour rendre cet exploit qui rend la calc hyper lente inutilisable.

Oui... N'empêche qu'ils sont débiles de resizer par pas de 10 handles

Ca, je l'avais dit depuis longtemps. Mais je ne pensais pas qu'ils augmentaient la taille par pas de seulement 10 (ou 20) handles... Ca doit carrément ralentir, à partir de 1700, non?

et pas qu'un peu!

[PasToutAfaitHS] C'est surtout pour ca que je l'ai pas fait pour PedroM [/PasToutAfaitHS]

[MaisQuandMemeUnToutPetitPeuHS] Heu il s'arrête à 1700 handles Pedrom? [/MaisQuandMemeUnToutPetitPeuHS]

[BrefDesoleDuHS]Nan, a 2000[/BrefDesoleDuHS]

[OnContinueLeHS]Bouh [/OnContinueLeHS]

Parce que TI allouent la table des handles sur le heap?

Pas vraiment (en fait avant l'estack). Mais elle peut être redimensionnée s'il n'y a pas de handle derrière qui bloque.

Ben si y'a l'estack derrière ça va forcément la bloquer?

Elle est loin derriere.

Euh je crois pas que ce soit une question de "loin derrière", je crois surtout que l'estack peut se déplacer dans certaines conditions, non?

Houlà! Pas très bon à mon avis s'il se déplace...