Pile et allocation mémoire - Page 2

ah ! ok !
Donc en fait, j'en utilise pas tant que ça...
Dans ce que j'ai donné, j'en ai peut-être oublié un ou deux, mais pas plus... Donc, a priori, c pas ça
Retour au point de départ...

Exact. Donc tu peux repasser tout tes trucs en "dynamiques", mais essaye de faire moins d'allocation mais plutôt d'en faire des plus grosses.

Si tu mets des données en statique ou en automatique, ça ne te rajoute aucun Handle!
Les variables statiques sont dans le Handle du programme asm.
Mais pour des données dynamiques, c'est un Handle par malloc. Mais un appel à realloc ne rajoute pas de Handle, normalement, puisque ça en redimensionne un (le déplaçant au besoin)

Ça plante à quel moment du programme exactement, et pour un fichier de quelle taille ?

Ben ça plante quand je tente d'ouvrir un fichier contenant 150 opérations banquaires.
Enfin, ça plante pas, parceque je récupère les erreurs, mais il arrive pas à ouvrir le fichier pour cause de manque de memoire : l'un des malloc echoue dans la fonction "ouvre" de fichier.c (si tu veux regarder les sources )

J'ai juste regardé vite-fait, et j'ai remarqué que tu stockes dans 'size' certaines infos, et tu fais un malloc(size+1). Le size est déclaré comme un char, cad qu'il peut valoir au maximum 127.
Il se peut que lorsque tu initialises size (avec size=*file, mais je ne sais pas ce qu'il y a dans file), la valeur de *file soit supérieure à 127, ce qui entrainerait un size négatif, qui pourrait faire échouer le malloc... Tu devrais déclarer size en unsigned char (voire en unsigned short, pour prévoir large)

Il y a plus de 2000 handles max... En fait c un peu complique.

jackiechan a écrit :
J'ai juste regardé vite-fait, et j'ai remarqué que tu stockes dans 'size' certaines infos, et tu fais un malloc(size+1). Le size est déclaré comme un char, cad qu'il peut valoir au maximum 127. Il se peut que lorsque tu initialises size (avec size=*file, mais je ne sais pas ce qu'il y a dans file), la valeur de *file soit supérieure à 127, ce qui entrainerait un size négatif, qui pourrait faire échouer le malloc... Tu devrais déclarer size en unsigned char (voire en unsigned short, pour prévoir large)

Nan, le probleme peut pas venir de là : size contient ici une valeur au maximum de 80. quand je fais size=*file, je récupère la longueur d'une chaine de caractères, qui est au maximum de 80. Ca, j'en suis sur, car a la création du fichier, je vérifie que les chaines soient de longueur inférieure a 80, donc il n'y a pas d'overflow ici...
En tous cas, merci d'avoir lu les sources

En tout cas, si c'est vraiment le nombre maximum de handles, alors il faudra probablement allouer des tableaux, des structures, ou des combinaisons plutôt que d'allouer des blocs de partout.

Essaye d'observer la valeur de HeapGetHandle(); à plusieurs moments.

oui, je parlais de variables du TIOS
(chaque variable du TIOS est un bloc mémoire, identifié par un HANDLE)

(arf, j'aurai peut-être du préciser)

Bon, je viens de trouver l'erreur !
En fait, il s'agit bien d'un cast, qui fait que la quantité de mémoire allouée est completement fausse...
Ca ressemble a ce qu'avait trouvé jackiechan, mais a un autre endroit de la meme fonction !
Ligne 91 il y avait ça :
c.nops = (*file<<8)+*(file+1);
Il fallait mettre ça :
c.nops = (unsigned short)(*file<<8)+(unsigned char)*(file+1);
sinon, pour 141 opérations banquaires, j'allouais la mémoire pour 64000... (environ, j'ai pas retenu le chiffre)

En tous cas, merci a vous de m'avoir aidé

Je viens de trouver un nouveau probleme, du a un bug de AMS :
Lorsque'on utilise des boites de dialogues et que le programme est archivé, ça plante. Chose bizarre, ça ne plantait pas en compilant avec une version plus ancienne de TIGCC (je compile maintenant avec la 0.94)...
Le #define SET_FILE_IN_USE_BIT est censé corriger ce bug, mais il semble que ça ne change rien. Pour coriger le probleme, je suis obligé de cacher le twin a la main !

Y aurait-il un probleme dans TIGCC ?

Quelle version de la 0.94 utilises-tu ? La Final, ou une des dernières bêtas ?

ben la final, sinon j'aurais précisé la beta

guilc a écrit :
Je viens de trouver un nouveau probleme, du a un bug de AMS :
Lorsque'on utilise des boites de dialogues et que le programme est archivé, ça plante. Chose bizarre, ça ne plantait pas en compilant avec une version plus ancienne de TIGCC (je compile maintenant avec la 0.94)...
Le #define SET_FILE_IN_USE_BIT est censé corriger ce bug, mais il semble que ça ne change rien. Pour coriger le probleme, je suis obligé de cacher le twin a la main !
Y aurait-il un probleme dans TIGCC ?

Argh... Remplis un formulaire "bug report" avec tous les détails qu'il nous faut s'il te plaît. En particulier, il nous faut une source avec laquelle on peut reproduire le bogue.

Ok, je vais le faire... Je vous file mon prog avec... C'est un peu gros, mais ça bugue bien
Je vais essayer de faire un truc plus petit qui bugue aussi

guilc a écrit :
Ok, je vais le faire... Je vous file mon prog avec... C'est un peu gros, mais ça bugue bien

OK.

Je vais essayer de faire un truc plus petit qui bugue aussi

Merci beaucoup, ça serait l'idéal.

vala, c'est fait....
Par contre, j'ai pas réussi a faire un code court qui plante bien.... Donc c'est un peu long, désolé
And sorry for my bad english

Wouah ! c'est du rapide !!!
J'ai déja eu la réponse de Sebastian Reichelt !
Voila sa réponse :

My first guess is that the problem is related to EXECUTE_IN_GHOST_SPACE. I will investigate this further.

I've found the bug. It is a serious mistake in tipatch.lib:

<| If %d3.w is 0, clear the in-use bit.
< move.l %d4,%a0
>| If %d3.w is 0, clear the in-use bit.
> move.l %d1,%a0

I have yet to test whether it really works, but the mistake is obvious.
Sebastian

Donc voila, le bug est trouvé semble-t-il . En tous cas, c'est du rapide ! Merci a toute l'équipe de TIGCC ! (et que ceux qui critiquent sans cesse la TIGCC Team en prennent de la graine...)

Attention, la correction proposée n'est pas correcte, parce que l'appel à HeapDeref pourrait avoir détruit d1. Sebastian m'a répondu qu'il va corriger ça correctement.

Et le problème n'est pas lié à EXECUTE_IN_GHOST_SPACE.

bah ! vous vous débrouillez entre vous pour corriger le bug
Du moment que dans la prochaine version de TIGCC, c'est corrigé, ça me va

Génial, cette nouvelle version marche très bine. Y a plus le bug.

Encore un détail : SET_FILE_IN_USE_BIT corrige un bug important d'AMS... Alors pourquoi ne pas le mettre par défaut ?

Parce que ça prend beaucoup de place et que, dans beaucoup de cas, ce n'est pas nécessaire. Personnellement, ça ne me dérangerait pas de le mettre par défaut, mais Sebastian a objecté pour la raison citée et je pense que Zeljko est également contre (il veut le minimum possible de startup code). Et puis si on le mettait par défaut, on récolterait pas mal de flames non justifiés comme quoi les programmes TIGCC deviennent de plus on plus gros etc. (N'est-ce pas, Thibaut? )

Oui, si on met SET_FILE_IN_USE_BIT par défaut, on va entendre que les programmes TIGCC deviennent de moins en moins _nostub, qu'ils sont de plus en plus gros (alors que pour diminuer un peu leur taille il suffit d'utiliser les options qui sont mises à disposition), que je ne sais quoi encore...

> il suffit d'utiliser les options qui sont mises à disposition
Mais certaines ralentissent

Pas celles qui suppriment le startup code dont tu n'as pas besoin. C'est vraiment débile de ta part de ne pas les utiliser. Ça optimise le code en taille et en vitesse de lancement.

"En vitesse de lancement"
C'est clair que c'est insuportable d'attendre 0,001 seconde pour lancer un programme

C'est vraiment débile de votre part de les inclure par défaut, de ne pas laisser le programmeur les choisir dans l'assistant de création de projets.

C'est vraiment débile de votre part de les inclure par défaut, de ne pas laisser le programmeur les choisir dans l'assistant de création de projets

je ne le dirai pas comme ça, mais c clair que ça serait pas mal de regrouper ces options avec des cases à cocher quelque part, en interface graphique

Thibaut
a écrit : C'est vraiment débile de votre part de les inclure par défaut, de ne pas laisser le programmeur les choisir dans l'assistant de création de projets.

Les options qui ne sont pas dans l'assistant sont les options pour programmeurs avancés (sauf les 2 les plus utilisées: SAVE_SCREEN et OPTIMIZE_ROM_CALLS), qui sont documentées sous http://tigcc.ticalc.org/doc/httigcc.html#advanced. On ne peut pas tout mettre dans l'assistant, sinon il devient tellement compliqué que ce n'est plus la peine d'avoir un assistant. Ce n'est pas de notre faute si tu ne lis pas la documentation. RTFM.

Mais on le sait très bien où elles sont ces options, mais personnellement, je dois chaque fois ouvrir la doc pour mettre les defines pour avoir un executable qui fasse moins de 100 octets. J'aimerais bien moi aussi qu'il existe une page pour choisir les options.
De plus le choix des options par défaut est plus que discutable, en particulier pour le support des exit. Enfin voilà...