[MorphOS] trouver les hits ;-)

[glames]

glames

#5784

Salut à tous,

Le portage de Word Me Up XXL avance bien. J’en suis à détecter les potentiels hits. Problème, je n’arrive pas à rendre le système assez « bavard » en cas d’erreur.

Voici mon programme de test avec quelques erreurs classiques:

#include

int main (void)

{

char *p_test;

strcpy(p_test, »hello world! »);

//free(p_test);

return(0);

}

J’ai lu la doc du SDK et passé le paramètre EDebugFlags= »permmemtrack » lors du lancement de MorphOS. J’ai également coché Memtracker dans les prefs debug du « System settings ».

Quand je lance mon programme de test, il bloque ce qui semble normal car on écrit dans une zone mémoire non allouée mais je n’ai aucun message me permettant de localiser l’erreur.

J’ai essayé de compiler mon programme avec -ggdb mais ça ne change rien. Si j’active le free final, j’ai un message de la ixemul.library: « free start of a block corrupt », ce qui est normal. Par contre, pas de détails non plus sur la localisation du soucis.

Donc, il y a sans doute quelque chose que je n’ai pas activé

Mais quoi?

Merci

Glames

[henes]

henes

#95697

http://www.biclodon.com/documentation/morphosdebug/

http://www.binaryriot.org/users/jacadcaps/logtool/

-noixemul à la compilation et à l’édition de liens

[ code]

Et return n’est pas une fonction

[glames]

glames

#95698

MErci, je m’en vais regarder tout ça

[corto]

corto

#95699

Voici des infos d’un autre thread, rapportées par Rmais96 et données par Fab sur IRC :

Pour résumer :

– GccFindHit ne fonctionne que pour des binaires 68k,

– objdump et ppc-morphos-objdump permettent de trouver la position d’un hit, respectivement pour des binaires 68k et PPC,

– l’exe doit être compilé avec l’option -g de Gcc,

– pour plus d’info, se référer au site de Henes :

http://www.biclodon.com/documentation/morphosdebug

Et d’un autre thread, des infos données par Fab (encore !), cette fois à propos des options de compilation pour l’utilisation avec logtool et aussi pour l’écriture des traces de debug dans ramdebug :

c’est écrit directement dans les prefs de logtool et dans le readme : -g à la compilation et -Wl,–traditional-format pour le link.

Après, logtool est censé être capable d’analyser tout ça (cela dit, je me demande si ça marche à tous les coups). A noter que tu peux aussi le faire manuellement avec objdump -d –source executable > dump, et ça ça marche à chaque fois.

Sinon, pour écrire dans le debuglog, tu peux utiliser kprintf. Tu inclus clib/debug_protos.h et tu linkes avec -ldebug.

Glames : Tu as des hits qui n’apparaissaient pas sous OS4 ?

[glames]

glames

#95700

@Corto,

Merci pour toutes ces précisions.

Pour l’instant, je n’ai pas de hit avéré. C’est plus par précaution.

Par contre, je profite de l’occasion pour poser une question sur un truc bizarre qui m’arrive. J’ai des archives zip peuvent être désarchivées sans problème sous OS 4.0. Par contre, sous Mos, il génère des erreurs (bib xadmaster) m’indiquant des problèmes de checksum (n° 17). Le problème m’arrive aussi via Voodoo X. J’ai vérifié l’intégrité par zip -T. Par contre, il semble que ça n’arrive qu’avec des archives que j’ai généré moi-même. J’ai fait le test avec des archives lha et j’ai le même soucis. Sachant que parfois, ça marche, parfois non… Mon install Mos est toute « propre » puisque très récente (suite à mon crash disk).

Y-a-t-il une version de la xadmaster.library spécifique pour Mos. Pour l’instant, j’utilise celle destiné au 68k (j’ai fait le test avec la 00, 020 et 060 avec les mêmes résultats).

Toute aide serait grandement appréciée!

Merci.

Glames

[Fab1]

Fab1

#95701

Toutes les versions de la xadmaster devraient passer. Tu crées tes archives avec quoi ? T’as un exemple d’une telle archive à uploader quelque part ?

Tu as un peg1 sans april ?

[glames]

glames

#95702

Salut Fab1,

C’est un peg 2: en tout cas, on me l’a vendu comme ça

Ce qui est bizarre, c’est que ça semble arriver qu’avec des archives que j’ai créé moi-même

J’ai mis à dispo un exemple ici http://boing.attitude.online.fr/wmupxxl_5.zip

J’ai zippé avec powerarchiver sous Win. J’ai aussi testé avec des lha faits directement en local sous MorphOS avec le même résultat.

Mais effectivement, ça serait intéressant de voir si tu as ce genre de problème. Si tu peux l’ouvrir 5 fois de suite sans problème, c’est que l’archive est bonne.

Bye et merci.

Glames

[Fab1]

Fab1

#95703

Aucun problème, l’archive s’ouvre bien avec xadmaster (ma version est native ppc, mais j’ai fait vérifier la version 68k sous 1.4 aussi).

Je suis un peu perplexe du coup… Une barrette mémoire capricieuse ? Des libraries en doublon plus ou moins incompatibles (mossys:libs/ sys:libs, …) ?

[EDIT]

Un problème de mask mal configuré sur tes partitions pourrait être une cause aussi. Essaie de tout faire en ram et compare.

[fenrix]

fenrix

#95704

en tout cas quand Word Me Up XXL sortira sur MorphOS, ça fera un Hit de plus pour l’OS

/me attends encore two more weeks

[glames]

glames

#95705

@Fab1,

Merci pour l’info. Ca confirme malheureusement ce que je pensais

@Fenrix,

Surement

Bye

Glames

[glames]

glames

#95706

@Fab1,

J’ai vérifié :pas de doublons dans mes bibs. J’ai xadmaster.library dans Mos:libs/. Dans libs, j’ai aussi deux répertoires xad et xadspecial. Tout semble normal, avec Snoopium an arrière-plan.

J’ai testé en RAM: mais ça ne change malheureusement rien… Vraiment bizarre.

Merci en tout cas pour ton aide.

Glames

[Brumiga]

Brumiga

#95707

@glames,

Supprime ce répertoire et son contenu. Voici 5 ans environ un responsable canadien de virus help team avait indiqué sur leur forum que les programmes xfd-xad et xfdscan étaient responsables de crashs pendant des scans par des programmes antivirus amiga.

Brumiga

[glames]

glames

#95708

@Brumiga,

Merci pour ton aide, malheureusement mais après avoir supprimé les deux sous-répertoires, ça ne fonctionne pas mieux…

[Edité pour des fautes de frappe]

Glames