Désolé de poster un peu en retard; mais j'ai lu un truc qui m'a terrifié il
y a un jour ou deux...
Je cite :
<QUOTE>
PAs exactement, sous Linux, l'allocation peut échouer (malloc peut
renvoyer NULL). Néanmoins, sous Linux, une allocation réussie ne
garantit pas à 100% que la zone de mémoire renvoyée puisse être utilisée.
</QUOTE>
En général, je vérifie que l'allocation reussit, genre
ptr = malloc(nanana)
if(!ptr)Traiter_problème (souvent exit...)
suite programme...
Dans quels cas le malloc est non NULL et le pointeur inutilisable ?
Comment être SUR que le résultat du malloc est utilisable ?
J'ai lu à la suite diverses considérations sur la robustesse du code, j'ai
rien percuté...
Dans quels cas le malloc est non NULL et le pointeur inutilisable ? Comment être SUR que le résultat du malloc est utilisable ?
Utiliser un OS qui marche. C'est-a-dire, un Unix autre que Linux, ou Linux avec le patch qui va bien pour supprimer l'overcommit.
Pour expliquer ce qui se passe: certaines personnes utilisent d'enormes tableaux tres creux, des physiciens entre autres. Ces gens ont surtout besoin de l'espace d'adressage, style, j'alloue 3G d'espace histoire d'avoir un tableau avec des indices de 0 a beaucoup, et j'utilise 25 elements dans tout cet espace. C'est un peu goret, mais parfois, ces gens ont surtout un calcul a faire, et se fichent un peu des aspects informatiques de la chose...
Linux, au lieu de faire les choses dans le bon sens, c'est-a-dire de fournir aux gens qui le demandent une interface pour faire de l'overcommit, est parti dans la direction opposee. Le resultat, eh bien c'est que malloc n'est pas d'une robustesse redoutable.
Mais bon, lorsqu'on arrive pres de la limite en terme d'espace memoire, linux degomme les process un peu au hasard pour recuperer la place (doit y avoir un bout de code pour eviter init et quelques autres), donc en cas d'espace memoire insuffisant, autant numeroter tes process pour les retrouver apres la catastrophe de toutes facons.
In article <bsc58k$ohj$1@news-reader5.wanadoo.fr>,
gpg <guignot@wanadoo.fr> wrote:
Dans quels cas le malloc est non NULL et le pointeur inutilisable ?
Comment être SUR que le résultat du malloc est utilisable ?
Utiliser un OS qui marche. C'est-a-dire, un Unix autre que Linux, ou
Linux avec le patch qui va bien pour supprimer l'overcommit.
Pour expliquer ce qui se passe: certaines personnes utilisent d'enormes
tableaux tres creux, des physiciens entre autres. Ces gens ont surtout
besoin de l'espace d'adressage, style, j'alloue 3G d'espace histoire
d'avoir un tableau avec des indices de 0 a beaucoup, et j'utilise 25
elements dans tout cet espace. C'est un peu goret, mais parfois, ces
gens ont surtout un calcul a faire, et se fichent un peu des aspects
informatiques de la chose...
Linux, au lieu de faire les choses dans le bon sens, c'est-a-dire de
fournir aux gens qui le demandent une interface pour faire de l'overcommit,
est parti dans la direction opposee. Le resultat, eh bien c'est que malloc
n'est pas d'une robustesse redoutable.
Mais bon, lorsqu'on arrive pres de la limite en terme d'espace memoire,
linux degomme les process un peu au hasard pour recuperer la place (doit
y avoir un bout de code pour eviter init et quelques autres), donc en cas
d'espace memoire insuffisant, autant numeroter tes process pour les
retrouver apres la catastrophe de toutes facons.
Dans quels cas le malloc est non NULL et le pointeur inutilisable ? Comment être SUR que le résultat du malloc est utilisable ?
Utiliser un OS qui marche. C'est-a-dire, un Unix autre que Linux, ou Linux avec le patch qui va bien pour supprimer l'overcommit.
Pour expliquer ce qui se passe: certaines personnes utilisent d'enormes tableaux tres creux, des physiciens entre autres. Ces gens ont surtout besoin de l'espace d'adressage, style, j'alloue 3G d'espace histoire d'avoir un tableau avec des indices de 0 a beaucoup, et j'utilise 25 elements dans tout cet espace. C'est un peu goret, mais parfois, ces gens ont surtout un calcul a faire, et se fichent un peu des aspects informatiques de la chose...
Linux, au lieu de faire les choses dans le bon sens, c'est-a-dire de fournir aux gens qui le demandent une interface pour faire de l'overcommit, est parti dans la direction opposee. Le resultat, eh bien c'est que malloc n'est pas d'une robustesse redoutable.
Mais bon, lorsqu'on arrive pres de la limite en terme d'espace memoire, linux degomme les process un peu au hasard pour recuperer la place (doit y avoir un bout de code pour eviter init et quelques autres), donc en cas d'espace memoire insuffisant, autant numeroter tes process pour les retrouver apres la catastrophe de toutes facons.
kilobug
<hs topic='linux'> L'allocation mémoire sous Linux est assez optimiste. Si tu demande plein de petits blocs - bien au delà de ce qui est réellement disponible -,
ça peut marcher aussi avec des gros blocs ;)
malloc() te dira gentiment 'oui oui'. Après, s'il n'y a pas moyen d'avoir un peu de mémoire dispo *au moment d'utiliser la mémoire*, dommage... Mais si ça plante à ce moment là, c'est de la faute du système, pas de la tienne.
certes (mais il faut toujours prévoir que le système puisse tuer le programme n'importe quand, que ce soit parce qu'un utilisateur a envoyé un SIGKILL ou autre, donc éviter autant que possible de compter sur une sortie normale du programme pour ce qui est important)
PAQJS, le seul moyen d'être sûr que la mémoire allouée est effectivement utilisable est d'essayer tout de suite d'écrire dans cette mémoire.
ça aide, mais ça ne garantie pas que le programme ne sera pas OOM-killé plus tard
Normalement le 2.6 corrige ce problème (bien que dans certains cas, comme le fork/exec ou les tableaux creux ça permette de faire fonctionner un programme qui ne tournerait pas autrement, ça crée plus de pb que ça n'en résoud)
-- Gael Le Mignot "Kilobug" - - http://kilobug.free.fr GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959 Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
<hs topic='linux'>
L'allocation mémoire sous Linux est assez optimiste. Si tu demande
plein de petits blocs - bien au delà de ce qui est réellement
disponible -,
ça peut marcher aussi avec des gros blocs ;)
malloc() te dira gentiment 'oui oui'. Après, s'il n'y a pas moyen
d'avoir un peu de mémoire dispo *au moment d'utiliser la mémoire*,
dommage... Mais si ça plante à ce moment là, c'est de la faute du
système, pas de la tienne.
certes (mais il faut toujours prévoir que le système puisse tuer le
programme n'importe quand, que ce soit parce qu'un utilisateur a
envoyé un SIGKILL ou autre, donc éviter autant que possible de compter
sur une sortie normale du programme pour ce qui est important)
PAQJS, le seul moyen d'être sûr que la mémoire allouée est
effectivement utilisable est d'essayer tout de suite d'écrire dans
cette mémoire.
ça aide, mais ça ne garantie pas que le programme ne sera pas
OOM-killé plus tard
Normalement le 2.6 corrige ce problème (bien que dans certains cas,
comme le fork/exec ou les tableaux creux ça permette de faire
fonctionner un programme qui ne tournerait pas autrement, ça crée plus
de pb que ça n'en résoud)
--
Gael Le Mignot "Kilobug" - kilobug@nerim.net - http://kilobug.free.fr
GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
<hs topic='linux'> L'allocation mémoire sous Linux est assez optimiste. Si tu demande plein de petits blocs - bien au delà de ce qui est réellement disponible -,
ça peut marcher aussi avec des gros blocs ;)
malloc() te dira gentiment 'oui oui'. Après, s'il n'y a pas moyen d'avoir un peu de mémoire dispo *au moment d'utiliser la mémoire*, dommage... Mais si ça plante à ce moment là, c'est de la faute du système, pas de la tienne.
certes (mais il faut toujours prévoir que le système puisse tuer le programme n'importe quand, que ce soit parce qu'un utilisateur a envoyé un SIGKILL ou autre, donc éviter autant que possible de compter sur une sortie normale du programme pour ce qui est important)
PAQJS, le seul moyen d'être sûr que la mémoire allouée est effectivement utilisable est d'essayer tout de suite d'écrire dans cette mémoire.
ça aide, mais ça ne garantie pas que le programme ne sera pas OOM-killé plus tard
Normalement le 2.6 corrige ce problème (bien que dans certains cas, comme le fork/exec ou les tableaux creux ça permette de faire fonctionner un programme qui ne tournerait pas autrement, ça crée plus de pb que ça n'en résoud)
-- Gael Le Mignot "Kilobug" - - http://kilobug.free.fr GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959 Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
Bruno Desthuilliers
gpg wrote:
Désolé de poster un peu en retard; mais j'ai lu un truc qui m'a terrifié il y a un jour ou deux...
Je cite :
<QUOTE> PAs exactement, sous Linux, l'allocation peut échouer (malloc peut renvoyer NULL). Néanmoins, sous Linux, une allocation réussie ne garantit pas à 100% que la zone de mémoire renvoyée puisse être utilisée. </QUOTE>
En général, je vérifie que l'allocation reussit, genre
ptr = malloc(nanana) if(!ptr)Traiter_problème (souvent exit...) suite programme...
Dans quels cas le malloc est non NULL et le pointeur inutilisable ? Comment être SUR que le résultat du malloc est utilisable ?
J'ai lu à la suite diverses considérations sur la robustesse du code, j'ai rien percuté...
C'est spécifique au système, donc HS ici.
<hs topic='linux'> L'allocation mémoire sous Linux est assez optimiste. Si tu demande plein de petits blocs - bien au delà de ce qui est réellement disponible -, malloc() te dira gentiment 'oui oui'. Après, s'il n'y a pas moyen d'avoir un peu de mémoire dispo *au moment d'utiliser la mémoire*, dommage... Mais si ça plante à ce moment là, c'est de la faute du système, pas de la tienne.
PAQJS, le seul moyen d'être sûr que la mémoire allouée est effectivement utilisable est d'essayer tout de suite d'écrire dans cette mémoire.
Mais comme je n'ai pas forcément tout bien compris aux subtilités de la gestion de mémoire sous Linux, il est fort possible que je sois en train de dire des c..., donc je te recommande un ng plus spécifique. </hs>
Bisous à tous, bonne dinde et merci d'avance.
<hs mode='encore_plus'>
Pour moi ce sera du magret (sud-ouest oblige), mais bon appétit à tous quand même !-) </hs>
Bruno
gpg wrote:
Désolé de poster un peu en retard; mais j'ai lu un truc qui m'a terrifié il
y a un jour ou deux...
Je cite :
<QUOTE>
PAs exactement, sous Linux, l'allocation peut échouer (malloc peut
renvoyer NULL). Néanmoins, sous Linux, une allocation réussie ne
garantit pas à 100% que la zone de mémoire renvoyée puisse être utilisée.
</QUOTE>
En général, je vérifie que l'allocation reussit, genre
ptr = malloc(nanana)
if(!ptr)Traiter_problème (souvent exit...)
suite programme...
Dans quels cas le malloc est non NULL et le pointeur inutilisable ?
Comment être SUR que le résultat du malloc est utilisable ?
J'ai lu à la suite diverses considérations sur la robustesse du code, j'ai
rien percuté...
C'est spécifique au système, donc HS ici.
<hs topic='linux'>
L'allocation mémoire sous Linux est assez optimiste. Si tu demande plein
de petits blocs - bien au delà de ce qui est réellement disponible -,
malloc() te dira gentiment 'oui oui'. Après, s'il n'y a pas moyen
d'avoir un peu de mémoire dispo *au moment d'utiliser la mémoire*,
dommage... Mais si ça plante à ce moment là, c'est de la faute du
système, pas de la tienne.
PAQJS, le seul moyen d'être sûr que la mémoire allouée est effectivement
utilisable est d'essayer tout de suite d'écrire dans cette mémoire.
Mais comme je n'ai pas forcément tout bien compris aux subtilités de la
gestion de mémoire sous Linux, il est fort possible que je sois en train
de dire des c..., donc je te recommande un ng plus spécifique.
</hs>
Bisous à tous, bonne dinde et merci d'avance.
<hs mode='encore_plus'>
Pour moi ce sera du magret (sud-ouest oblige), mais bon appétit à tous
quand même !-)
</hs>
Désolé de poster un peu en retard; mais j'ai lu un truc qui m'a terrifié il y a un jour ou deux...
Je cite :
<QUOTE> PAs exactement, sous Linux, l'allocation peut échouer (malloc peut renvoyer NULL). Néanmoins, sous Linux, une allocation réussie ne garantit pas à 100% que la zone de mémoire renvoyée puisse être utilisée. </QUOTE>
En général, je vérifie que l'allocation reussit, genre
ptr = malloc(nanana) if(!ptr)Traiter_problème (souvent exit...) suite programme...
Dans quels cas le malloc est non NULL et le pointeur inutilisable ? Comment être SUR que le résultat du malloc est utilisable ?
J'ai lu à la suite diverses considérations sur la robustesse du code, j'ai rien percuté...
C'est spécifique au système, donc HS ici.
<hs topic='linux'> L'allocation mémoire sous Linux est assez optimiste. Si tu demande plein de petits blocs - bien au delà de ce qui est réellement disponible -, malloc() te dira gentiment 'oui oui'. Après, s'il n'y a pas moyen d'avoir un peu de mémoire dispo *au moment d'utiliser la mémoire*, dommage... Mais si ça plante à ce moment là, c'est de la faute du système, pas de la tienne.
PAQJS, le seul moyen d'être sûr que la mémoire allouée est effectivement utilisable est d'essayer tout de suite d'écrire dans cette mémoire.
Mais comme je n'ai pas forcément tout bien compris aux subtilités de la gestion de mémoire sous Linux, il est fort possible que je sois en train de dire des c..., donc je te recommande un ng plus spécifique. </hs>
Bisous à tous, bonne dinde et merci d'avance.
<hs mode='encore_plus'>
Pour moi ce sera du magret (sud-ouest oblige), mais bon appétit à tous quand même !-) </hs>
Bruno
gpg
Bruno Desthuilliers wrote:
C'est spécifique au système, donc HS ici.
D'accord, mais s'agissant d'une demande d'éclaircissement concernant un message lu sur ce forum, ce n'est pas totalement ridicule de la poster sur le dit forum, non?
Bruno Desthuilliers wrote:
C'est spécifique au système, donc HS ici.
D'accord, mais s'agissant d'une demande d'éclaircissement concernant un
message lu sur ce forum, ce n'est pas totalement ridicule de la poster sur
le dit forum, non?
D'accord, mais s'agissant d'une demande d'éclaircissement concernant un message lu sur ce forum, ce n'est pas totalement ridicule de la poster sur le dit forum, non?
Gabriel Dos Reis
(Marc Espie) writes:
| Mais bon, lorsqu'on arrive pres de la limite en terme d'espace memoire, | linux degomme les process un peu au hasard pour recuperer la place (doit | y avoir un bout de code pour eviter init et quelques autres),
en fait, je sais pas : un jour, ma machine avait rebooté (c'était en 1999). Évidemment c'était l'un de ces bloatware (Net$cape en l'occurance) qui merdait.
-- Gaby
espie@tetto.gentiane.org (Marc Espie) writes:
| Mais bon, lorsqu'on arrive pres de la limite en terme d'espace memoire,
| linux degomme les process un peu au hasard pour recuperer la place (doit
| y avoir un bout de code pour eviter init et quelques autres),
en fait, je sais pas : un jour, ma machine avait rebooté (c'était en 1999).
Évidemment c'était l'un de ces bloatware (Net$cape en l'occurance) qui
merdait.
| Mais bon, lorsqu'on arrive pres de la limite en terme d'espace memoire, | linux degomme les process un peu au hasard pour recuperer la place (doit | y avoir un bout de code pour eviter init et quelques autres),
en fait, je sais pas : un jour, ma machine avait rebooté (c'était en 1999). Évidemment c'était l'un de ces bloatware (Net$cape en l'occurance) qui merdait.
-- Gaby
Gabriel Dos Reis
gpg writes:
| Bruno Desthuilliers wrote: | > | > C'est spécifique au système, donc HS ici. | | D'accord, mais s'agissant d'une demande d'éclaircissement concernant un | message lu sur ce forum, ce n'est pas totalement ridicule de la poster sur | le dit forum, non?
Pas du tout.
-- Gaby
gpg <guignot@wanadoo.fr> writes:
| Bruno Desthuilliers wrote:
| >
| > C'est spécifique au système, donc HS ici.
|
| D'accord, mais s'agissant d'une demande d'éclaircissement concernant un
| message lu sur ce forum, ce n'est pas totalement ridicule de la poster sur
| le dit forum, non?
| Bruno Desthuilliers wrote: | > | > C'est spécifique au système, donc HS ici. | | D'accord, mais s'agissant d'une demande d'éclaircissement concernant un | message lu sur ce forum, ce n'est pas totalement ridicule de la poster sur | le dit forum, non?
Pas du tout.
-- Gaby
kilobug
(Marc Espie) writes: | Mais bon, lorsqu'on arrive pres de la limite en terme d'espace memoire, | linux degomme les process un peu au hasard pour recuperer la place (doit | y avoir un bout de code pour eviter init et quelques autres),
en fait, je sais pas : un jour, ma machine avait rebooté (c'était en 1999). Évidemment c'était l'un de ces bloatware (Net$cape en l'occurance) qui merdait.
C'était un 2.0 ? Je crois que l'OOM-killer date du 2.2, peut-être même pas du début du 2.2 (je dis bien je crois, je peux me tromper)
-- Gael Le Mignot "Kilobug" - - http://kilobug.free.fr GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959 Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
espie@tetto.gentiane.org (Marc Espie) writes:
| Mais bon, lorsqu'on arrive pres de la limite en terme d'espace memoire,
| linux degomme les process un peu au hasard pour recuperer la place (doit
| y avoir un bout de code pour eviter init et quelques autres),
en fait, je sais pas : un jour, ma machine avait rebooté (c'était en 1999).
Évidemment c'était l'un de ces bloatware (Net$cape en l'occurance) qui
merdait.
C'était un 2.0 ? Je crois que l'OOM-killer date du 2.2, peut-être même pas
du début du 2.2 (je dis bien je crois, je peux me tromper)
--
Gael Le Mignot "Kilobug" - kilobug@nerim.net - http://kilobug.free.fr
GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
(Marc Espie) writes: | Mais bon, lorsqu'on arrive pres de la limite en terme d'espace memoire, | linux degomme les process un peu au hasard pour recuperer la place (doit | y avoir un bout de code pour eviter init et quelques autres),
en fait, je sais pas : un jour, ma machine avait rebooté (c'était en 1999). Évidemment c'était l'un de ces bloatware (Net$cape en l'occurance) qui merdait.
C'était un 2.0 ? Je crois que l'OOM-killer date du 2.2, peut-être même pas du début du 2.2 (je dis bien je crois, je peux me tromper)
-- Gael Le Mignot "Kilobug" - - http://kilobug.free.fr GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959 Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
Gabriel Dos Reis
(Gaël Le Mignot) writes:
| > Évidemment c'était l'un de ces bloatware (Net$cape en l'occurance) qui | > merdait. | | C'était un 2.0 ? Je crois que l'OOM-killer date du 2.2, peut-être même pas | du début du 2.2 (je dis bien je crois, je peux me tromper)
2.2.x -- je ne me souviens plus de la valeur de x.
-- Gaby
kilobug@freesurf.fr (Gaël Le Mignot) writes:
| > Évidemment c'était l'un de ces bloatware (Net$cape en l'occurance) qui
| > merdait.
|
| C'était un 2.0 ? Je crois que l'OOM-killer date du 2.2, peut-être même pas
| du début du 2.2 (je dis bien je crois, je peux me tromper)
2.2.x -- je ne me souviens plus de la valeur de x.
| > Évidemment c'était l'un de ces bloatware (Net$cape en l'occurance) qui | > merdait. | | C'était un 2.0 ? Je crois que l'OOM-killer date du 2.2, peut-être même pas | du début du 2.2 (je dis bien je crois, je peux me tromper)
2.2.x -- je ne me souviens plus de la valeur de x.
-- Gaby
Marwan FeanoR/var Burelle
On Wed, 24 Dec 2003 14:19:35 +0000 (UTC) (Marc Espie) wrote:
Mais bon, lorsqu'on arrive pres de la limite en terme d'espace memoire, linux degomme les process un peu au hasard pour recuperer la place (doit y avoir un bout de code pour eviter init et quelques autres)
Pas dans tous les cas ... je l'ai déjà vu tuer init ou d'autre process "nécessaires" (c'était en TP d'ailleurs, sont farceur ces étudiants ... )
On Wed, 24 Dec 2003 14:19:35 +0000 (UTC)
espie@tetto.gentiane.org (Marc Espie) wrote:
Mais bon, lorsqu'on arrive pres de la limite en terme d'espace memoire,
linux degomme les process un peu au hasard pour recuperer la place
(doit y avoir un bout de code pour eviter init et quelques autres)
Pas dans tous les cas ... je l'ai déjà vu tuer init ou d'autre process
"nécessaires" (c'était en TP d'ailleurs, sont farceur ces étudiants ... )
On Wed, 24 Dec 2003 14:19:35 +0000 (UTC) (Marc Espie) wrote:
Mais bon, lorsqu'on arrive pres de la limite en terme d'espace memoire, linux degomme les process un peu au hasard pour recuperer la place (doit y avoir un bout de code pour eviter init et quelques autres)
Pas dans tous les cas ... je l'ai déjà vu tuer init ou d'autre process "nécessaires" (c'était en TP d'ailleurs, sont farceur ces étudiants ... )
Dans quels cas le malloc est non NULL et le pointeur inutilisable ? Comment être SUR que le résultat du malloc est utilisable ?
Utiliser un OS qui marche. C'est-a-dire, un Unix autre que Linux, ou Linux avec le patch qui va bien pour supprimer l'overcommit.
Pas besoin de patch. Sur mon noyau 2.4.18 sur mon UltraSparc, par défaut, l'overcommit est désactivé, et activable simplement en écrivant un '1' dans /proc/sys/vm/overcommit_memory (ça n'est possible qu'en étant root). C'est également le cas sur mon vieux Pentium avec un noyau 2.2.20. En regardant les sources du noyau 2.4.18, par contre, je remarque que l'overcommit est activé par défaut sur l'architecture arm, et c'est tout.
Pour expliquer ce qui se passe: certaines personnes utilisent d'enormes tableaux tres creux, des physiciens entre autres. Ces gens ont surtout besoin de l'espace d'adressage, style, j'alloue 3G d'espace histoire d'avoir un tableau avec des indices de 0 a beaucoup, et j'utilise 25 elements dans tout cet espace. C'est un peu goret, mais parfois, ces gens ont surtout un calcul a faire, et se fichent un peu des aspects informatiques de la chose...
Linux, au lieu de faire les choses dans le bon sens, c'est-a-dire de fournir aux gens qui le demandent une interface pour faire de l'overcommit, est parti dans la direction opposee. Le resultat, eh bien c'est que malloc n'est pas d'une robustesse redoutable.
Mais bon, lorsqu'on arrive pres de la limite en terme d'espace memoire, linux degomme les process un peu au hasard pour recuperer la place (doit y avoir un bout de code pour eviter init et quelques autres), donc en cas d'espace memoire insuffisant, autant numeroter tes process pour les retrouver apres la catastrophe de toutes facons.
Je ne vois pas comment un système Bien Conçu (tm) pourrait se sortir de cette situation sans tuer quelques process. Si un goret demande 3G de mémoire et qu'on le lui accorde, ou si un programmeur compétent demande 3G en ayant au préalable demandé au noyau d'autoriser cette demande même s'il ne peut pas la satisfaire, et que finalement le programme a réellement besoin de toute cette mémoire, comment le noyau est-il supposé faire la différence? Il doit tuer le process qui a demandé 3G?
Si vous jetez un oeil dans le fichier mm/oom_kill.c d'un noyau 2.4.18, vous trouvez l'algo de choix du process à killer, il est simple, il s'agit de donner une note à chaque process, et la note varie en fonction: - de la quantité de mémoire consommée (la note est au départ la quantité de mémoire allouée au process) - du temps CPU et du runtime utilisé (la note est divisée par la racine carrée du temps CPU consommé, puis par la racine quatrième du runtime) - de la priorité du process (un process qui a un 'niceness' supérieur à 0 voit sa note doublée) - du privilège du process (un process ayant un uid ou euid à 0 voit sa note divisée par 4) - de l'accès ou non à du matériel (un process qui accède directement au matériel voit sa note divisée par 4)
Maintenant si on donne les droits root au physicien qui code comme un goret, il ne faut pas s'étonner que le noyau tue les processus du voisin...
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Je n'ai pas envie de perdre mon temps à leur APD à la con. Mais j'ai besoin du certificat qu'y est délivré, pour passer le permis. J'ai entendu qu'on le trouvait sur Internet. Quelqu'un aurait-il des infos? -+- DC in GNU : Neuneu s'achète une conduite -+-
On Wed, 24 Dec 2003, Marc Espie wrote:
In article <bsc58k$ohj$1@news-reader5.wanadoo.fr>,
gpg <guignot@wanadoo.fr> wrote:
Dans quels cas le malloc est non NULL et le pointeur inutilisable ?
Comment être SUR que le résultat du malloc est utilisable ?
Utiliser un OS qui marche. C'est-a-dire, un Unix autre que Linux, ou
Linux avec le patch qui va bien pour supprimer l'overcommit.
Pas besoin de patch. Sur mon noyau 2.4.18 sur mon UltraSparc, par défaut,
l'overcommit est désactivé, et activable simplement en écrivant un '1'
dans /proc/sys/vm/overcommit_memory (ça n'est possible qu'en étant root).
C'est également le cas sur mon vieux Pentium avec un noyau 2.2.20. En
regardant les sources du noyau 2.4.18, par contre, je remarque que
l'overcommit est activé par défaut sur l'architecture arm, et c'est tout.
Pour expliquer ce qui se passe: certaines personnes utilisent d'enormes
tableaux tres creux, des physiciens entre autres. Ces gens ont surtout
besoin de l'espace d'adressage, style, j'alloue 3G d'espace histoire
d'avoir un tableau avec des indices de 0 a beaucoup, et j'utilise 25
elements dans tout cet espace. C'est un peu goret, mais parfois, ces
gens ont surtout un calcul a faire, et se fichent un peu des aspects
informatiques de la chose...
Linux, au lieu de faire les choses dans le bon sens, c'est-a-dire de
fournir aux gens qui le demandent une interface pour faire de l'overcommit,
est parti dans la direction opposee. Le resultat, eh bien c'est que malloc
n'est pas d'une robustesse redoutable.
Mais bon, lorsqu'on arrive pres de la limite en terme d'espace memoire,
linux degomme les process un peu au hasard pour recuperer la place (doit
y avoir un bout de code pour eviter init et quelques autres), donc en cas
d'espace memoire insuffisant, autant numeroter tes process pour les
retrouver apres la catastrophe de toutes facons.
Je ne vois pas comment un système Bien Conçu (tm) pourrait se sortir de
cette situation sans tuer quelques process. Si un goret demande 3G de
mémoire et qu'on le lui accorde, ou si un programmeur compétent demande 3G
en ayant au préalable demandé au noyau d'autoriser cette demande même s'il
ne peut pas la satisfaire, et que finalement le programme a réellement
besoin de toute cette mémoire, comment le noyau est-il supposé faire la
différence? Il doit tuer le process qui a demandé 3G?
Si vous jetez un oeil dans le fichier mm/oom_kill.c d'un noyau 2.4.18,
vous trouvez l'algo de choix du process à killer, il est simple, il s'agit
de donner une note à chaque process, et la note varie en fonction:
- de la quantité de mémoire consommée (la note est au départ la
quantité de mémoire allouée au process)
- du temps CPU et du runtime utilisé (la note est divisée par la racine
carrée du temps CPU consommé, puis par la racine quatrième du runtime)
- de la priorité du process (un process qui a un 'niceness' supérieur à 0
voit sa note doublée)
- du privilège du process (un process ayant un uid ou euid à 0 voit sa
note divisée par 4)
- de l'accès ou non à du matériel (un process qui accède directement au
matériel voit sa note divisée par 4)
Maintenant si on donne les droits root au physicien qui code comme un
goret, il ne faut pas s'étonner que le noyau tue les processus du
voisin...
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Je n'ai pas envie de perdre mon temps à leur APD à la con. Mais j'ai
besoin du certificat qu'y est délivré, pour passer le permis. J'ai
entendu qu'on le trouvait sur Internet. Quelqu'un aurait-il des infos?
-+- DC in GNU : Neuneu s'achète une conduite -+-
Dans quels cas le malloc est non NULL et le pointeur inutilisable ? Comment être SUR que le résultat du malloc est utilisable ?
Utiliser un OS qui marche. C'est-a-dire, un Unix autre que Linux, ou Linux avec le patch qui va bien pour supprimer l'overcommit.
Pas besoin de patch. Sur mon noyau 2.4.18 sur mon UltraSparc, par défaut, l'overcommit est désactivé, et activable simplement en écrivant un '1' dans /proc/sys/vm/overcommit_memory (ça n'est possible qu'en étant root). C'est également le cas sur mon vieux Pentium avec un noyau 2.2.20. En regardant les sources du noyau 2.4.18, par contre, je remarque que l'overcommit est activé par défaut sur l'architecture arm, et c'est tout.
Pour expliquer ce qui se passe: certaines personnes utilisent d'enormes tableaux tres creux, des physiciens entre autres. Ces gens ont surtout besoin de l'espace d'adressage, style, j'alloue 3G d'espace histoire d'avoir un tableau avec des indices de 0 a beaucoup, et j'utilise 25 elements dans tout cet espace. C'est un peu goret, mais parfois, ces gens ont surtout un calcul a faire, et se fichent un peu des aspects informatiques de la chose...
Linux, au lieu de faire les choses dans le bon sens, c'est-a-dire de fournir aux gens qui le demandent une interface pour faire de l'overcommit, est parti dans la direction opposee. Le resultat, eh bien c'est que malloc n'est pas d'une robustesse redoutable.
Mais bon, lorsqu'on arrive pres de la limite en terme d'espace memoire, linux degomme les process un peu au hasard pour recuperer la place (doit y avoir un bout de code pour eviter init et quelques autres), donc en cas d'espace memoire insuffisant, autant numeroter tes process pour les retrouver apres la catastrophe de toutes facons.
Je ne vois pas comment un système Bien Conçu (tm) pourrait se sortir de cette situation sans tuer quelques process. Si un goret demande 3G de mémoire et qu'on le lui accorde, ou si un programmeur compétent demande 3G en ayant au préalable demandé au noyau d'autoriser cette demande même s'il ne peut pas la satisfaire, et que finalement le programme a réellement besoin de toute cette mémoire, comment le noyau est-il supposé faire la différence? Il doit tuer le process qui a demandé 3G?
Si vous jetez un oeil dans le fichier mm/oom_kill.c d'un noyau 2.4.18, vous trouvez l'algo de choix du process à killer, il est simple, il s'agit de donner une note à chaque process, et la note varie en fonction: - de la quantité de mémoire consommée (la note est au départ la quantité de mémoire allouée au process) - du temps CPU et du runtime utilisé (la note est divisée par la racine carrée du temps CPU consommé, puis par la racine quatrième du runtime) - de la priorité du process (un process qui a un 'niceness' supérieur à 0 voit sa note doublée) - du privilège du process (un process ayant un uid ou euid à 0 voit sa note divisée par 4) - de l'accès ou non à du matériel (un process qui accède directement au matériel voit sa note divisée par 4)
Maintenant si on donne les droits root au physicien qui code comme un goret, il ne faut pas s'étonner que le noyau tue les processus du voisin...
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Je n'ai pas envie de perdre mon temps à leur APD à la con. Mais j'ai besoin du certificat qu'y est délivré, pour passer le permis. J'ai entendu qu'on le trouvait sur Internet. Quelqu'un aurait-il des infos? -+- DC in GNU : Neuneu s'achète une conduite -+-
