Sous Linux, avec l'OOM Killer activé, malloc ne retourne jamais NULL. Et donc les applications n'ont aucune chance de pouvoir intercepter et traiter l'erreur. Elles se font tuer directement
C'est un peu (mais alors vraiment «un peu» hein, pas beaucoup) plus subtil que ça.
De mémoire, l'overcommit à 3 réglages:
0
Heuristic overcommit handling. Obvious overcommits of address space are refused. Used for a typical system. It ensures a seriously wild allocation fails while allowing overcommit to reduce swap usage. root is allowed to allocate slightly more memory in this mode. This is the default.
1
Always overcommit. Appropriate for some scientific applications. Classic example is code using sparse arrays and just relying on the virtual memory consisting almost entirely of zero pages.
2
Don’t overcommit. The total address space commit for the system is not permitted to exceed swap + a configurable amount (default is 50%) of physical RAM. Depending on the amount you use, in most situations this means a process will not be killed while accessing pages but will receive errors on memory allocation as appropriate.
Trad grossière:
0: rejet des demandes ridicules, c'est à dire supérieure à un seuil réglable.
1: plus de mémoire? Rien à foutre, en voici.
2: pas d'overcommit, mon préféré pour tout système sur lequel je fais des trucs que j'ai pas envie de perdre pour cause de freeze.
Après, il paraît, mais j'ai plus le lien, qu'ils ont corrigé le problème de l'oomkiller qui se déclenchait trop tard. Perso, je m'en fout, j'ai toujours considéré cette feature comme un appel à coder comme des porcs, chose que je ne considère pas normale. Perso, je préfère un système prévisible, qui ne tuera pas au hasard une application critique parce qu'elle ose accéder à un espace mémoire que le noyau lui à pourtant réservé ni ne partira en thrashing.
[^] # Re: Encore un qui n’utilise pas assez GNU/Linux
Posté par freem . En réponse au lien Le désenchantement du logiciel. Évalué à 5.
C'est un peu (mais alors vraiment «un peu» hein, pas beaucoup) plus subtil que ça.
De mémoire, l'overcommit à 3 réglages:
Trad grossière:
0: rejet des demandes ridicules, c'est à dire supérieure à un seuil réglable.
1: plus de mémoire? Rien à foutre, en voici.
2: pas d'overcommit, mon préféré pour tout système sur lequel je fais des trucs que j'ai pas envie de perdre pour cause de freeze.
Après, il paraît, mais j'ai plus le lien, qu'ils ont corrigé le problème de l'oomkiller qui se déclenchait trop tard. Perso, je m'en fout, j'ai toujours considéré cette feature comme un appel à coder comme des porcs, chose que je ne considère pas normale. Perso, je préfère un système prévisible, qui ne tuera pas au hasard une application critique parce qu'elle ose accéder à un espace mémoire que le noyau lui à pourtant réservé ni ne partira en thrashing.