PreOS v0.70 fait il un HeapLock? - Page 1

Bonjour!

Je suis tombé sur un bug avec PCT, et apres pas mal de temps pour l isoler avec VTI je
me suis rendu compte que c t Api92 qui se déplacait.
en fait j appelais un HeapCompress avant de faire HeapAvail. (c ptet pas tres malin
de faire des HeapCompress, mais bon... en tous cas je l'ai enlevé). c t le HeapCompress
qui réarrangeait la mémoire, et dans les conditions du bug il deplacait
aussi Api92 alors qu elle etait en utilisation.

donc il semble qu'il n y ait pas eut de HeapLock sur Api92.
est ce que c voulu de la part de PreOS ?

parce que je pense pas que les programmes fassent un HeapCompress, mais avec
des HeapAlloc dans certaines conditions ca doit aussi faire des réarrangements de
mémoire. et donc 1 fois sur 1000 ca pourrait faire planter le truc non ?


Sinon une autre question pour PpHd : quand un programme est archivé et qu on
l execute, ca rajoute une entrée bizarre dans la VAT, une variable qui fait 4 octets.
genre : 00 02 00 F8 04 08
c t juste pour savoir a quoi ca servait. (j aurais pu regarder dans les sources mais
j ai pas eut le temps). et ce que signifiat le 00 F8, c pas un handle valide apparement.


Merci bcp!
Ben

donc il semble qu'il n y ait pas eut de HeapLock sur Api92.
est ce que c voulu de la part de PreOS ?

a priori nan

où est ajoutée l'entrée bizarre dans la VAT ? j'ai pas ça
et le handle est tout à fait valide. C'est une variable de type OTH qui fait 4o. Je pense que c'est pour réserver le nom de la variable sans lui allouer le contenu. Comme certaines fonctions risques de bugguer si le handle d'une variable est nul, il faut lui donner un contenu (ici le plus petit possible, soit 4o)

un moment je pensais que ct api92 qui faisait le coup, j'avais pas réalisé que BenShe == Benoît Scherrer et que donc tu devrais le savoir, si ct api92

Euh, ce serait une bonne idée de laisser le HeapCompress, ne serait-ce que parce qu'il vaut mieux que ça bugge tout le tps qu'une fois sur 100...

Flanker :
Comme certaines fonctions risques de bugguer si le handle d'une variable est nul, il faut lui donner un contenu (ici le plus petit possible, soit 4o)

Si c le cas, alors les fonctions en question sont buggées : pour le calcul de régression (regcoef...), je crois que le tios laisse traîner des variables avec un handle nul dans certains cas... Il vaudrait mieux corriger les progs qui foirent dans ce cas-là...



Sinon pour être sûr que c bien un bug de PreOS, surveille avec VTI les écritures dans le mot qui précède api92 : au moins tu sauras si api92 a été locké à un moment donné ou pas du tout...

il me semble que ça arrive quand on veut effacer le double d'un prog archivé dont on a retiré le handle.

Ok merci bien!
je vais regarder ca pour le lock

et merci aussi pour les variables de 4octets. ca doit bien etre ca.
sinon juste dans le flag 04 00 le bit 00000100 00000000
est officiel pour le TIOS? (ou juste non utilisé)

Ben

c'est le bit twin / temporaire, nan ? justement pour signaler que c'est une copie temporaire d'un prog archivé (si le bit archivé est armé)

>donc il semble qu'il n y ait pas eut de HeapLock sur Api92. est ce que c voulu de la part de PreOS ?
Mais le Handle des libraries est locke. C'est meme la premiere chose que Preos fait avant de la reloger.
Je verifie...
Non meme pour les fichiers compresses, il fait un HeapAllocHighThrow.

Sur quel AMS ? Heu sinon Preos 0.70 est buggue au niveau des libraries, prend une RC de Preos 0.71 plutot.
Peux-tu m'envoyer un mail contenant le zip du probleme ?

>Sinon une autre question pour PpHd : quand un programme est archivé et qu on
>l execute, ca rajoute une entrée bizarre dans la VAT, une variable qui fait 4 octets.
>genre : 00 02 00 F8 04 08


>c t juste pour savoir a quoi ca servait. (j aurais pu regarder dans les sources mais
>j ai pas eut le temps). et ce que signifiat le 00 F8, c pas un handle valide apparement.
Preos purge la copie du fichier archive, puisqu'il n'en a pas besoin, et travaille directement sur le fichier archive.
(ce qui fait que si ton programme possede le flag ReadOnly, il est VRAIMENt execute en memoire archive).

>Si c le cas, alors les fonctions en question sont buggées : pour le calcul de régression (regcoef...), je crois que le tios laisse traîner des variables avec un handle nul dans certains cas... Il vaudrait mieux corriger les progs qui foirent dans ce cas-là...
Il n'y pas que ce probleme.

>sinon juste dans le flag 04 00 le bit 00000100 00000000
>est officiel pour le TIOS? (ou juste non utilisé)
Preos > 0.70 ne modifie plus du tout la VAT, donc c'est le TIOS qui a mis ce flag

PpHd :
>sinon juste dans le flag 04 00 le bit 00000100 00000000
>est officiel pour le TIOS? (ou juste non utilisé)
Preos > 0.70 ne modifie plus du tout la VAT, donc c'est le TIOS qui a mis ce flag

Dans ce cas, c'est PreOs 0.7x qui bogue. Cf. SET_FILE_IN_USE_BIT. Tu dois mettre le bit in-use si tu crées un twin, sinon AMS va effacer le handle quand il a envie, ce qui crée exactement le bogue que Ben reporte.

>Dans ce cas, c'est PreOs 0.7x qui bogue. Cf. SET_FILE_IN_USE_BIT.
>Tu dois mettre le bit in-use si tu crées un twin, sinon AMS va effacer le handle quand il a envie, ce qui crée exactement le bogue que Ben reporte.

Mais il n'y a plus de twin, puisque tout est interne, donc plus besoin de mettre ce flag.
D'ailleurs je serai curieux de savoir a qui tu voulais que je mettre ce flag puisque le programme execute n'existe pas dans la VAT.
Regarde dans les explorateurs style pct / doors. Tu verras un gros changement par rapport aux 0.6x lorsque tu regardes l'etat de la VAT.

J ai regarde ca avec Vti

oui Preos lock bien Api92, mais avec une routine perso.
ensuite avec le hasard des choses je faisais un HeapLock
sur api92, normal, puis un HeapUnlock, normal aussi.
manque de bol ca delock pour de vrai api92!! vu
que preos semble faire son lock perso, il prend pas
en compte le nb de HeapLock!

sinon un autre pb me semble t il : Quand on execute un
prog, ca lock et ca delock bien. PAR CONTRE avec kernel::exec
le programme reste locké apres!! j ai regardé dans le source,
il y a bien un tios::HLock, mais pas de unlock (ou alors il
est caché)


voila. dit moi ce que t en penses PphD !!

A+
Ben

BenSche :
oui Preos lock bien Api92, mais avec une routine perso.
ensuite avec le hasard des choses je faisais un HeapLock sur api92, normal, puis un HeapUnlock, normal aussi.

Non, pas normal!!! HeapUnlock déverrouille toujours ton handle, peu importe le nombre de HeapLock appelés avant! Il faut faire un HeapGetLock avant ton HeapLock pour avoir l'état d'origine.

sinon un autre pb me semble t il : Quand on execute un
prog, ca lock et ca delock bien. PAR CONTRE avec kernel::exec
le programme reste locké apres!! j ai regardé dans le source,
il y a bien un tios::HLock, mais pas de unlock (ou alors il est caché)

En revanche, ça, c'est un bogue de PreOs.

Oups, c'est vrai. Faut que je reflechisse ou le faire.

PpHd-> comment fais-tu pour exécuter un prog en archive?
Il ne doit pas être relogé?

Mais si. Mais pas par le tios.

Link
: PpHd-> comment fais-tu pour exécuter un prog en archive?

Il le copie en RAM. Mais pas avec un symbole twin.

ok!

ok merci pour le HeapLock. Je pensais vriament que y avait un compteur. C
grave comme erreur ... :-)