Rajah (./85) :
Wow, on apprend tous les jours. Merci Stabylo pour ces informations

De rien

Rajah (./85) :
Sinon, un truc tout bête : MagiC a horreur des malloc avec des tailles impaires. Il te vire sec si c'est pas pair. En général, ça va bien parce que les structures sont composées de int et long et pointeurs, mais s'il y a alloc mémoire d'un fichier ayant une taille impaire, ça va bomber.

Ca peut venir du fait qu'il place un canari à la fin du bloc, et que c'est un long mot. Alors sur 68k, boum !

Rajah (./85) :
Pour ça qu'on voit souvent des ajustements de la taille au prochain multiple de 2 ou 4 : genre malloc(((taille + 4) >> 2) << 2)

toutafé. on peut aussi considérer l'écrire comme ça : malloc((taille + 3) & -4)

Rajah (./85) :
Sinon, je trouve assez saine cette protection de débordement mémoire. Un programme n'a pas à faire caca en dehors de son domaine.

Certes... Mais il manque sans doute un coup de pouce pour déboguer les applis en développement.

frost (./86) :
Et MagiC fournit-il un moyen de débugger ça ?

Pas que je sache . Le plus gros souci, c'est que ça se gaufre à la libération du bloc, c'est-à-dire à un moment où tu ne sais plus du tout à quoi il correspondait, ce fichu bloc duquel tu as débordé.

Il faut alors se montrer créatif. Dans Animator, ce que j'ai fait, c'est un système maison similaire, mais qui cette fois me permet de savoir exactement où dans le code j'ai alloué le bloc de mémoire qui pose souci.

Ca repose sur les macros removers Malloc/Mfree (fichier macros.s/gemdos.s, lignes 506 à 588) pour assemble. En activant un EQU (__DEBUG_MALLOC_CANARIES), la macro rajoute des canaris et aussi l'adresse du code depuis laquelle la macro a été appelée. Ca donne ainsi une idée d'où vient le bloc.

frost (./86) :
Je vais tâcher de reprendre le patch 060 pour Adebug un de ces 4.

Ouille, si la CT a fait "pshit!", c'est sans doute compromis là, non ?