J'ai le problème suivant: un programme a un bogue comme celui-ci
int main() {
for(;;) {
char *p = (char*)std::malloc(1024);
std::memset(p, 1, 1024);
}
}
Et cela continue à allouer de la mémoire jusqu'à ce que mon système commence à échanger des pages d'autres applications en faveur de ce programme et que je ne puisse plus rien faire dans la boîte. J'ai rencontré ce problème plusieurs fois avec différentes applications (aujourd'hui, c'était avec Moonlight 2 beta dans Firefox). Si le problème vient du fait que le programme provoque l’échange de la mémoire d’un autre programme et qu’il peut utiliser davantage de mémoire physique.
Naturellement, j’ai examiné ulimit et trouvé deux réglages:
-m
la taille maximale de l'ensemble résident de
-v
la taille de la mémoire virtuelle
J'ai lu que le premier indique la taille totale de la mémoire physique que le processus peut utiliser à la fois. Pour moi, il semble que cela soit plus raisonnable que la taille totale de la mémoire virtuelle, car elle peut être partagée, et cela pourrait n'avoir aucune importance, car elle est de toute façon remplacée. J'ai donc ajouté ce qui suit à mon article .bashrc
après avoir examiné la taille habituelle des ensembles de résidents top
, allant jusqu'à environ 120 Mo pour une session firefox habituelle, que j'ai trouvée.
# limit usage to 256MB physical memory out of 1GB
ulimit -m 262144
Mais après l' exécution de mon extrait de test ci - dessus, il reste Brough mon système vers le bas, et je dû attendre environ 5 minutes jusqu'à ce que le terminal a reconnu mes ^C
touches. Habituellement, si je ne réagis pas dans les toutes premières secondes, dans ces situations, je ne peux que cliquer sur le bouton de réinitialisation, ce que je n'aime vraiment pas - quelqu'un a-t-il une stratégie pour résoudre ce problème? Pourquoi la limitation physique ne fonctionne-t-elle pas? Il me semble que de cette façon, les autres applications devraient toujours disposer de suffisamment de mémoire physique pour réagir de manière sensée.
-m
la quantité de mémoire physique utilisée, le virtual est limité. Donc, le processus va échanger. J'ai lu que tous les types de support Shell / Linux ne sont pas supportés-m
. Vous pouvez vérifier ce qui est réellement défini aveculimit -a
ou aveculimit -m
(sans paramètre)Je pense que l’implémentation d’Ulimimit est aléatoire sur presque tous les systèmes d’exploitation. J'utilise ulimit -S -v sous Linux depuis six ans. Six! Et il semble que certains noyaux ne le supportent plus. J'ai un Mac et OS X 10.6 ne le supporte pas. J'ai aussi essayé avec -m. Dans mon ancien bureau avec Ubuntu 9.04, ulimit -S -v fonctionne bien.
En effet, je cherche une vraie solution à cela. Je ne peux tout simplement pas croire que les utilisateurs d’Apple, par exemple, permettent à leur programme de se déchaîner en mémoire.
la source
Fuite de mémoire classique. J'ai bien peur qu'il faille corriger l'application en question, le système d'exploitation ne peut pas faire grand chose. Tout ce que le système d'exploitation peut faire est de restreindre la mémoire d'une application, mais l'application en question plantait / segfault et entraînait peut-être le système d'exploitation ou au moins xorg avec elle.
Vous pouvez ld_preload une autre version de malloc et ajouter un thread pour le libérer après un nombre de secondes spécifié. Je doute que cela fonctionne, cependant ...
Vous auriez besoin de ce tut: http://lattice.umiacs.umd.edu/files/functions_tr.pdf
la source