Protection mémoire sous MOS ?

[leo]

leo

#104818

@Henes: excuses moi… mais t’es vraiment lourd.

J’en sais foutrement rien si Valgrind est un truc qui dépend de l’OS, ou si ca se compile avec un simple make, et donc fonctionnerait sur MorphOS: c’est pour ça que j’ai posé la question. *Point barre*. Je ne déchante rien du tout. Alors stop avec ta paranoïa 5 minutes.

Désolé, mais alors vraiment désolé de ne pas en savoir autant que toi (ou Fab)… Mais vraiment désolé…. .

[Anonyme]

Anonyme

#104819

trop lourd ? de parcourir une liste chainée, avant d’autoriser l’allocation memoire :

struct free_mem {

ulong start_adress;

ulong end_adress;

bool used;

free_mem first;

free_mem next;

free_mem prev;

};

je dois me tromper mais la protection memoire via liste chainé ne consomme plus trop de ressources ? (si implementé dans alloc mem)

// mode edit : si toutes les fonctions qui alloues testent leur end_address allouées… poke and peek :: je sort

[WickedVinz]

WickedVinz

#104820

@Henes et Leo: arrêtez vos chahutages…

Pour ta gouverne Henes, il s’avère que la réponse à la question de Leo pouvait intéresser d’autres personnes (moi en l’occurence) et que je préfère grandement la réponse de Leo à la tienne…

Enfin, pourquoi un fil qui, bien que débattant d’un sujet maintes fois discuté ici, démarrait bien doit-il toujours terminer ainsi?

Eviter à l’avenir les réponses non constructives…

[Fab1]

Fab1

#104821

[edit] (c’est quoi ce doublon ?)

[Fab1]

Fab1

#104822

Madmin,

sauf que ça protège pas grand chose en fait.

[corto]

corto

#104823

Si la discussion peut permettre de faire découvrir des outils comme splint, valgrind ou des options de compilateurs, elle aura été utile.

Alex : splint a plusieurs niveaux, le plus léger (mode weak je crois), relève bien plus de warnings que gcc avec -Wall (je ne sais pas par rapport à toutes les options que tu as indiquées). Du genre :

– aucun warnings avec GCC

– 3 warnings avec l’option -Wall

– 30 avec splint en mode weak

– 120 avec splint en mode severe (je ne me souviens plus du nom)

C’est juste pour donner un ordre de grandeur.

leo : Henes est inflexible, ça peut énerver mais il ne faut pas s’en tenir à la forme. Il est exigeant et c’est un programmeur noble, dans le sens où il a un sens élevé de la qualité logicielle.

Bon, parfois il tombe dans l’excès, il faut aussi penser aux contraintes de la réalité.

J’utilise Valgrind sur Linux PPC, c’est une mine ! Il t’indique par exemple la ligne où tu as alloué de la mémoire et que tu ne l’as jamais relâchée. Ou la ligne où tu copies et que tu fais un dépassement de buffer.

Bien sûr dans le cas d’applications MUI, cette partie du code n’est pas testable. Mais à mon sens, dans un programme, tout le traitement compliqué doit pouvoir être extrait du code de l’interface. Et ça, rien ne t’empêche de le tester pour valider les modules. Ca demande un effort de conception mais ça aussi, c’est savoir bien développer.

Je vais être vague pour masquer ma méconnaissance technique mais il crée un environnement d’exécution (merci la protection mémoire) et ce n’est pas possible sous MorphOS.

Edit : J’en remets une louche sur Valgrind. Il trace toutes les opérations mémoire, il est même possible de voir la mémoire max occupée lors de l’exécution, suivre la courbe, … je l’ai utilisé pour PointRider.

[henes]

henes

#104824

@Wv

Peut-être que cela t’intéressait mais ce n’était pas forcément le cas de leo

Après tant d’années, il faudrait *vraiment* qu’il ait le réflexe (la volonté, en fait…) d’utiliser google *avant* de poser une question (surtout sur un sujet qu’il connait et à propos d’un outil qu’il a déjà touché…)…

Il y a une sacrée différence entre avoir tenté de trouver la réponse et avoir échoué / ne pas l’avoir compris… et sytématiquement (oui, c’est presque systématique maintenant) demander aux autres de faire le boulot de recherche/tri… Si tout le monde faisait cela à chaque fois, où irait-on…

Arrivé à un point, il faut arrêter de prendre les autres pour des idiots…

Fin du HS.

[leo]

leo

#104825

Merci Corto pour le petit topo sur Valgrind (même si avec google n’importe quel lecteur de ce forum aurait pu trouver ces informations). Je suis sûr que ça intéressera plein de monde, y compris moi.

Je l’avais utilisé en FAC mais j’avais pas été aussi loin. Je me rappelle juste qu’on avait des points en moins sur les TPs s’il y avait des fuites mémoire avec Valgrind… Ca c’était du prof

@Corto: c’est quoi la différence entre splint et valgrind ? splint c’est plutot à la compilation, non ?

[corto]

corto

#104826

leo : Très bien ce prof !

Le sujet est parti un peu dans tous les sens mais splint et valgrind n’ont rien à voir :

– splint analyse le code source et indique les problèmes sans exécution ni compilation du code. Comme dirait le commentaire du premier lien « splint » dans google : « Splint is a tool for statically checking C programs for security vulnerabilities and coding mistakes. »

– valgrind permet très simplement d’exécuter un programme et il trace toutes les opérations mémoires (accès, copies, allocations et libérations, …). A la sortie du programme, il donne un bilan pour localiser les erreurs qui ses ont réellement produites.

L’un est préventif, l’autre curatif.

[Alex]

Alex

#104827

Corto:

ben fais donc un test avec le GCC du SDK OS4 et les options que je t’ai fournies, tu vas être surpris A mon avis c’est juste une histoire d’activer tout les warnings possibles dans GCC (cf. la liste)

Concernant Valgrind je ne sais pas je ne l’ai jamais utilisé, mais bon apparemment il ne fait rien de nouveau, Rational Purify faisait ça depuis longtemps. Le problème avec ce genre d’outils c’est que dans des projets un peu complexe il a tendance à s’emmêler les pinceaux (par exemple au boulot dès que tu commençais à faire du DCOM il te mettait des erreurs de partout comme quoi tu allouais de la mémoire et que tu ne la libérais pas, etc.) bref c’est bien mais fait faire attention et ne pas suivre aveuglément.

[leo]

leo

#104828

De mémoire il y a –pedantic aussi si vous voulez beaucoup de warnings sur GCC

[Alex]

Alex

#104829

Leo:

Exact (enfin c’est juste -pedantic, pas de double tiret), mais c’est à réserver à certains programmeurs grincheux

[henes]

henes

#104830

Pour nos amis anglophobes anti google : un liens pour lister et expliquer pas mal d’outils d’aide à la programmation dont Valgrind et Splint.

[Tcheko]

Tcheko

#104831

Alex a écrit :

[…] bref c’est bien mais fait faire attention et ne pas suivre aveuglément.

Héhé. Ca me rappelle l’histoire au sujet du SSH de Debian il y a quelques mois de ça.

Un des gars utilisait un outil de contrôle de code et il a modifié le code de génération des clés pour SSH. L’outil lui disait qu’une variable n’était pas initialisée… Manque de pot celle ci participait largement à l’entropie de la clé…

[Fab1]

Fab1

#104832

j’ai aussi pas mal utilisé rational purify au boulot, mais le problème est qu’il est très très chatouilleux et plantogène, du moins sous windows.