J'utilise Electric Fence, un outil pour détecter les fuites de mémoires avec gdb, le problème c'est qu'il n'a pas l'air de libérer la mémoire qu'il utilise un fois l'exécution terminée. Ensuite je vais taper dans le swap. Y'a t'il un moyen de libérer la RAM sans redémarrer?

Il y a des dizaines de topics qui traite du problème de mémoire soit disant non libérée par  les applications. Linux gère correctement la mémoire. Il alloue la mémoire aux applications. Les binaires des applications reste dans en mémoire tant qu'il y a de la place, meme après qu'elle soit terminée. De cette manière si tu as re-besoin de cette application, elle se chargera plus vite.
 
Une fois que ta RAM est consommée, les pages mémoires les plus anciennes sont passées en SWAP pour libérer de la place en RAM (plus rapide).
 
Précisément qu'est ce qui te fais penser que tu as des problemes ?
As tu des ralentissements important ?

Regarde ce lien si ca peut éclairer les propos:
http://forums.gentoo.org/viewtopic [...] moire.html

J'ai l'impression que lorsque j'interromps l'exécution avec ctrl+Z ou C et que je débuggue pas à pas, la mémoire n'est plus bien libérée ensuite.
 
Pour info voilà ce qu'il fait entre autres:
 

 
Mon appli ouvre de gros fichiers, plus de 8Go, alors si je me mets à swapper c'est plus possible...

ouai ton lien est très intéressant, bon bein...je vais chercher autre chose alors, je consomme peut-être trop de mémoire...

sudo kill -9 pidof X
 

est-ce qu'un programme peut planter avec un segmentation fault s'il n'a plus de mémoire vive? Parce que là c'est quand ma RAM tombe à zéro que ça plante chez moi, je pensais que le swap empéchait ça

Tu as donc un autre probleme. L'erreur de segmentatuion vient probablement du fait que ton programme ne la produit que dans des conditions données.

ok merci

tu peux purger le /proc/numero de processus qui est celui du processus interrompu mais qui a peut pas liberer la mémoire peut etre que ça va libere au moins la taille equivalante des la somme des fichiers ouverts
/proc/numero/fd/liste_des_fichiers
 

Je n'ai pas très bien compris ton message désolé, notament : /proc/numero/fd/liste_des_fichiers  

le repertoire /proc/numero du processus/fd/ contient la liste des fichiers utilisés par le proessus en le detruisant tu liberes une taille memoire egale à au moins la somme des tailles de ces fichiers:
 

voilà deux exemples
 
si tu tues ces processus (et/ou en detruisant ces repertoire) tu recupères la place egalle au deux fichier log et pour le processus oracle tu recupererai de la meme facon la somme des tailles des fichiers suivants
client_sqlnet.log
tnsus.msb
ocius.msb
oraus.msb
orainit.LOCK  
immaginons que chaque fichier ferai 1Mega ça te libere 5Mega de ram en tuant ce processus (n° 3483) au minimum  
pourquoi au minimum ? parcequ'il peut aussi y avoir des DATAS et des ZONES de memoire reservées en plus de ça ....  
 
 
 
 

ok très instructif merci

Mytho. Laisse le noyau faire son travail.
Si ça t'amuse d'avoir de la RAM pour qu'elle soit vide, c'est toi qui voit. Enlève une barette, ça le fera plus surement.
Sérieusement mon chéri :
- ça ne peut pas planter si tu n'a plus de RAM. C'est juste que malloc de donnera NULL ou new lancera une exception.
- le noyau sait ce qu'il a à faire. Si y a des trucs swappés, c'est qu'il a trouvé mieux à mettre en RAM.
- ne croit pas l'autre supfrs31
 
Les gars, lsof c'est quand même plus friendly et ça donne plus de détail.
 
supfrs31 > explication complètement fausse. n'importe quoi. rm -rf / pour libérer de la RAM, vas-y on t'attends.

 
efence utilise la MMU ... ce qu'il faut pas lire. mais vraiment n'importe quoi. efence il fait des mprotect et voila. A part le noyau, personne ne voit la MMU ni de loin ni de près. Les gars faut vraiment faire la part entre matos / noyau / utilisateur.
 
T'es en 64bits ? ton fichier tu le mmap ou tu ne fais que le lire ? c'est SIGSEGV ou SIGBUS tu manges ?
 
Et laisse tomber efence, utilise valgrind, c'est bien meilleur.

64 bits oui, sur une machine avec 16Go de ram. Tout compte fait le fichier est bien lu, c'est quand je dois écrire dans la mémoire que ça plante. Bien sûr ça plante dans une lib qui n'est pas à moi... Bien sûr en mode débug sous gdb ça ne plante pas... Je vais voir du côté de valgrind, ce qui me fait chier c'est que efence me jète en me disant que y'a plus assez de mémoire au bout d'un moment, j'espère que ça va pas faire pareil. Merci en tout cas.

efence c'est obsolète aussi hein. chuck chuck lapinou

 
personne n'a jamais dit ca boulet apprends a lire
 
je parles bien de virer de la RAM et uniquement de la ram les fichiers qui y sont charger par un processus precis qui ne s'est pas stoppe  et rien d'autre j'ai bien precise que ce rm se faisant dans /rpoc/numero/fd et nule par ailleur.
 
apprends l'informatique et la programmation systeme en particulier et quand tu sera moins gosse revients sur le forum.
Viens passes a la maison j'ai beaucoup a t'apprende visiblement e ce sera avec grand plaisir  
 
oui tout fichier ouvert est copie en ram (dumoins la partie de fichier qui est utilisee a l'instant T), si tu n'es pas capable de comprendre ca tu n'a rien a faire sur un forum informatique et plus grave encore tu essayes de conseiller les autres ...
 
Pour purger ces elements de la ram il faut effacer leur copie dans la ram apres avoir choisi ceux que tu veux retirer et ceux que tu ne veux pas retirer...  
 
bien sur c'est vrai tuer un processus fait ce meme travaille mais quand le kill echoue tu fais quoi ? bha sans ma methode au bout de X problemes de processus que tu n'a pas tuer, tu n'a plus de ram et ta machine peu planter ou etre ralentie et comme un ane tu rebootes...
bravo la solution un gros downtime... si c'etait une machine de prod ca pourrai couter des centaines d'euros pour un simple reboot...
 
meditez ca !
 

Ha oui, j'avais pas lu ça ...  c'est joli ...    

Je suis pas sur que tu ais bcp à apprendre à Taz, ou à qui que ce soit d'autre, surtout quand on te lit ...
 
 
Maintenant, ceci s'adresse à Taz et à toi : Prochain "dérapage", c'est la sanction immédiate. Entre adultes, y'a d'autres moyens pour se faire comprendre et dialoguer que les insultes et provocations gratuites.
 
A bon entendeur, salut.

Il suffit pour empecher les derapages que mr taz cesses de dire n'importe quoi du genre "il n'existe pas de copie d'un fichier ouvert dans la ram"
 
 

Montres moi où il a écrit ça.
 
Fais un copier-coller exact d'un passage d'un de ses posts où il a dit ça de façon explicite.

c'est tres precisement ce que j'explique et il repond texto :

autrement dit cela est faux = il n'existe pas de copie des fichier ouvert dans la ram

C'est bien ce que je pensais ... tu interprètes la réponse de Taz, et mal en plus.
 
Il fallait comprendre "N'écoutes pas supfrs31, il te raconte des conneries dangereuses ..."
 
Je sais pas où tu as appris "la programmation système" comme tu dis, mais tu ferais bien de tout revoir, de façon rigoureuse.

Tient y'a de l'ambiance à ma soirée c'est sympa
 
 
Bon j'ai lancé mon programme avec Valgrind en partant du boulot. 6 heures et 20Go de ram plus tard j'ai le message d'erreur suivant:
 

 
J'ai parcouru toule code fortran de la bibliothèque qui plante et qui ne m'appartient pas, les indices ont l'air correct mais les allocations/désallocations ne sont pas testées : est-ce qu'en 64 bits avec 16Go de Ram et autant de swap le système peut décider qu'il ne veut plus allouer de la mémoire?
 
En attentant j'ai demandé aux concepteurs de la lib fortran de tester leurs allocations et désallocations et de me refournir une lib...
 
 
 

Non, ça n'a rien à voir avec les dimensions de ton système. Ni avec les allocations puisque t'as une corruption sur une libération. Là t'es un peu dans un mauvais cas, il va falloir débugguer et tracer d'où vient le morceau dont la libération pause problème. T'as peut etre un heap overflow ailleurs. Pas d'autres erreurs dans valgrind ? Je sais que valgrind est lent, mais tu vois, c'est puissant. Est-ce que tu as la même erreur sur plusieurs exécutions ?

Ca depend uniquement de ton systeme hein . Faut voir combien tu as de RAM + combien tu as de swap, un fois ce quota depassé, le systeme, il peut plus !

mais taz a raison, a prioris, c'est un probleme de desallocation rien d'autre.

Non. Si c'est alloué, alors c'est possible, c'est réservé. Le système répond. Si une allocation échoue, ça lève une exception ou bien ça renvoie NULL (selon C++ ou C).

Trop rapide taz, t'a pas eu le temps de voir mon edit. on est parfaitement d'accord, c'est le systeme qui alloue ou non et c'est a toi de gerer..

En fait Valgrind m'aurait prévenu si un tableau n'avait pas été alloué avant d'écrire dedans?  
 
Le truc chiant là c'est que la ligne indiquée dans le fichier fortran ne contient aucune désallocation, c'est un appel de fonction fortran qui remplit un tableau, c'est tout. Donc j'ai peur qu'il me donne une mauvaise ligne...
 
J'ai lancé un autre test, je pourrai comparer dans quelques heures. C'est arrivé que ça ne plate pas exactement au même endroit avec gdb. Mais à quelques lignes près. Je vais bien voir.
 
 
ps: Pas d'autre erreur pertinente dans Valgrind

Et t'as essayé avec des ficheirs de test beaucoup plus petit pour voir si ça se passait bien ?
 
Dans ton cas ça peut sembler pertinent, vu qu'il est possible que tu ai atteint une limite de conf systéme (genre mémoire/user ou nbre de fichier ouver ou limite de pages mémoire etc), si ça se passe bien avecdes fichiers plus petits t'as peut être interet à verifier la dedans.
 
Pour le reste je suis pas programmeur donc mon aide sera totalement innefficace

Avec un fichier plus petit ça passe et Valgrind ne signale aucun problème. Ca se passe seulement sur les très gros cas. Je n'ouvre qu'un seul fichier à la fois, et niveau limitations mémoire je pense que je suis bon :
 

si t'avais un truc pas alloué, ça ferait un SIGSEGV direct avec un pointeur null. Pour les lignes, bah il faut que tu sois sur de te référer au code qui a été compilé hein. Si t'as une libc récente, tu peux jouer avec MALLOC_CHECK_ / MALLOC_PERTURB_. En debuggant t'as vu des trucs ou pas ? des pointeurs bizarres ? (et pour debugger, faut bien recompiler tout en -O0 sinon ça n'est même pas la peine).

j'ai pas débuggué c'est pas évident de chopper un breakpoint correct dans le code fortran, et dans 6 heures
Pour les lignes les sources ont pas bougé depuis 1 an pour des binaire récents.
 
Pour MALLOC_CHECK_ / MALLOC_PERTURB_ , j'utilisais pas (évidemment...), mais peut-on les utiliser en même temps? Ca n'a pas l'air incompatible.

mais t'as pas une backtrace de ton crash ?
 
Pour les MALLOC, je ne sais pas, certainement pas. C'est une solution plus light a valgrind quand même, tu lances dans un gdb et tu attends le plantage.
 
Recompile ton code fortran sans optim si tu peux.

HAHA! Quand je lance l'appli en debug linkée à la lib fortran en debug sous gdb ça plante pas, donc pas de backtrace

heisenbug

lance quand même dans valgrind ce soir.