char *v = malloc(100000000);
for (i=1;i<1000000;i++)
v[i]=(v[i-1]+3)%200; // pour pas que le malloc se fasse optimiser,
//on sait jamais
printf("%d\n",42);
Le 03/02/08 14:27, dans <20080203132306$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C3CAAF4A.C4911%, Eric Levenez écrit:
Le 02/02/08 22:58, dans <20080202215127$, « Vincent Lefevre » <vincent+ a écrit :
Ce choix a quand même le gros problème de ne pas pouvoir réagir proprement.
"proprement" ? Ce choix a l'avantage d'être dynamique et est en concordance avec le swap qui n'utilise pas une place limitée par une partition dédiée. Si on veut vraiment tester sous Mac OS X (ou un autre Unix) la place retournée par malloc, il suffit de la remplir par un pattern.
Non, ça ne teste rien du tout. Ça force l'allocation, et s'il n'y a pas assez de mémoire, le programme plante!
Il faut bien sûr trapper les signaux. Il y a des bibliothèques qui encapsulent le malloc si le programmeur ne sait pas le faire. Le programme qui teste la mémoire réellement disponible de cette façon, ne plante pas, bien évidemment :-D
Il n'y a pas de réservation comme sur les dernières versions de Linux si c'est cela que tu veux dire.
Sur les dernières versions de Linux, c'est configurable.
Sur GNU/Linux il y a tellement de noyaux, de malloc différents, de configurations de l'overcommit, qu'un programme aura du mal à savoir si le pointeur retourné par malloc pointe sur une zone allouée physiquement.
Le programme n'a pas besoin de savoir. Il suffit juste de tester la valeur de retour. Et si l'utilisateur a configuré son noyau de manière à ne pas (trop) surallouer, en général, le programme ne plantera pas (s'il est bien écrit).
De toute façon, si le programme Linux alloue trop de place, et même si cela semble marcher du point de vue du malloc, le noyau peut très bien tuer celui qui a osé allouer toute cette ram, et cela dans la microseconde qui suit.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 03/02/08 14:27, dans <20080203132306$2d70@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Dans l'article <C3CAAF4A.C4911%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> écrit:
Le 02/02/08 22:58, dans <20080202215127$61dd@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Ce choix a quand même le gros
problème de ne pas pouvoir réagir proprement.
"proprement" ? Ce choix a l'avantage d'être dynamique et est en concordance
avec le swap qui n'utilise pas une place limitée par une partition dédiée.
Si on veut vraiment tester sous Mac OS X (ou un autre Unix) la place
retournée par malloc, il suffit de la remplir par un pattern.
Non, ça ne teste rien du tout. Ça force l'allocation, et s'il n'y a pas
assez de mémoire, le programme plante!
Il faut bien sûr trapper les signaux. Il y a des bibliothèques qui
encapsulent le malloc si le programmeur ne sait pas le faire. Le programme
qui teste la mémoire réellement disponible de cette façon, ne plante pas,
bien évidemment :-D
Il n'y a pas de réservation comme sur les dernières versions de
Linux si c'est cela que tu veux dire.
Sur les dernières versions de Linux, c'est configurable.
Sur GNU/Linux il y a tellement de noyaux, de malloc différents, de
configurations de l'overcommit, qu'un programme aura du mal à savoir si le
pointeur retourné par malloc pointe sur une zone allouée physiquement.
Le programme n'a pas besoin de savoir. Il suffit juste de tester la
valeur de retour. Et si l'utilisateur a configuré son noyau de manière
à ne pas (trop) surallouer, en général, le programme ne plantera pas
(s'il est bien écrit).
De toute façon, si le programme Linux alloue trop de place, et même si cela
semble marcher du point de vue du malloc, le noyau peut très bien tuer celui
qui a osé allouer toute cette ram, et cela dans la microseconde qui suit.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 03/02/08 14:27, dans <20080203132306$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C3CAAF4A.C4911%, Eric Levenez écrit:
Le 02/02/08 22:58, dans <20080202215127$, « Vincent Lefevre » <vincent+ a écrit :
Ce choix a quand même le gros problème de ne pas pouvoir réagir proprement.
"proprement" ? Ce choix a l'avantage d'être dynamique et est en concordance avec le swap qui n'utilise pas une place limitée par une partition dédiée. Si on veut vraiment tester sous Mac OS X (ou un autre Unix) la place retournée par malloc, il suffit de la remplir par un pattern.
Non, ça ne teste rien du tout. Ça force l'allocation, et s'il n'y a pas assez de mémoire, le programme plante!
Il faut bien sûr trapper les signaux. Il y a des bibliothèques qui encapsulent le malloc si le programmeur ne sait pas le faire. Le programme qui teste la mémoire réellement disponible de cette façon, ne plante pas, bien évidemment :-D
Il n'y a pas de réservation comme sur les dernières versions de Linux si c'est cela que tu veux dire.
Sur les dernières versions de Linux, c'est configurable.
Sur GNU/Linux il y a tellement de noyaux, de malloc différents, de configurations de l'overcommit, qu'un programme aura du mal à savoir si le pointeur retourné par malloc pointe sur une zone allouée physiquement.
Le programme n'a pas besoin de savoir. Il suffit juste de tester la valeur de retour. Et si l'utilisateur a configuré son noyau de manière à ne pas (trop) surallouer, en général, le programme ne plantera pas (s'il est bien écrit).
De toute façon, si le programme Linux alloue trop de place, et même si cela semble marcher du point de vue du malloc, le noyau peut très bien tuer celui qui a osé allouer toute cette ram, et cela dans la microseconde qui suit.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Vincent Lefevre
Dans l'article <C3CBCD23.C49B8%, Eric Levenez écrit:
Le 03/02/08 14:27, dans <20080203132306$, « Vincent Lefevre » <vincent+ a écrit :
Non, ça ne teste rien du tout. Ça force l'allocation, et s'il n'y a pas assez de mémoire, le programme plante!
Il faut bien sûr trapper les signaux.
Mais le signal en question (s'il est trappable) n'est pas défini de manière portable. Et comme tu le dis ci-dessous:
De toute façon, si le programme Linux alloue trop de place, et même si cela semble marcher du point de vue du malloc, le noyau peut très bien tuer celui qui a osé allouer toute cette ram, et cela dans la microseconde qui suit.
Oui, mais la cause première de ce comportement anormal est bien la surallocation. J'imagine que quelqu'un qui a lancé un très gros programme de calcul tournant depuis plusieurs jours et qui voit son programme tué de cette manière doit être content. :)
Dans l'article <C3CBCD23.C49B8%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> écrit:
Le 03/02/08 14:27, dans <20080203132306$2d70@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Non, ça ne teste rien du tout. Ça force l'allocation, et s'il n'y a pas
assez de mémoire, le programme plante!
Il faut bien sûr trapper les signaux.
Mais le signal en question (s'il est trappable) n'est pas défini de
manière portable. Et comme tu le dis ci-dessous:
De toute façon, si le programme Linux alloue trop de place, et même
si cela semble marcher du point de vue du malloc, le noyau peut très
bien tuer celui qui a osé allouer toute cette ram, et cela dans la
microseconde qui suit.
Oui, mais la cause première de ce comportement anormal est bien la
surallocation. J'imagine que quelqu'un qui a lancé un très gros
programme de calcul tournant depuis plusieurs jours et qui voit
son programme tué de cette manière doit être content. :)
Dans l'article <C3CBCD23.C49B8%, Eric Levenez écrit:
Le 03/02/08 14:27, dans <20080203132306$, « Vincent Lefevre » <vincent+ a écrit :
Non, ça ne teste rien du tout. Ça force l'allocation, et s'il n'y a pas assez de mémoire, le programme plante!
Il faut bien sûr trapper les signaux.
Mais le signal en question (s'il est trappable) n'est pas défini de manière portable. Et comme tu le dis ci-dessous:
De toute façon, si le programme Linux alloue trop de place, et même si cela semble marcher du point de vue du malloc, le noyau peut très bien tuer celui qui a osé allouer toute cette ram, et cela dans la microseconde qui suit.
Oui, mais la cause première de ce comportement anormal est bien la surallocation. J'imagine que quelqu'un qui a lancé un très gros programme de calcul tournant depuis plusieurs jours et qui voit son programme tué de cette manière doit être content. :)
À (at) Sun, 3 Feb 2008 13:27:42 +0000 (UTC), Vincent Lefevre <vincent+ écrivait (wrote):
Dans l'article <C3CAAF4A.C4911%, Eric Levenez écrit:
Le 02/02/08 22:58, dans <20080202215127$, « Vincent Lefevre » <vincent+ a écrit :
Ce choix a quand même le gros problème de ne pas pouvoir réagir proprement.
"proprement" ? Ce choix a l'avantage d'être dynamique et est en concordance avec le swap qui n'utilise pas une place limitée par une partition dédiée. Si on veut vraiment tester sous Mac OS X (ou un autre Unix) la place retournée par malloc, il suffit de la remplir par un pattern.
Non, ça ne teste rien du tout. Ça force l'allocation, et s'il n'y a pas assez de mémoire, le programme plante!
Le manuel de malloc (sur MacOS X) évoque la variable d'environnement 'MallocPreScribble' pour préremplir l'espace alloué par 0xaa.
De plus, que la mémoire soit allouée immédiatement ou de manière paresseusse, le fait que 'malloc' retourne un pointeur et que errno ne soit pas positionné à ENOMEM devrait quand même indiqué que la mémoire est potentiellement allouable. Ce qui est pourtant en contradiction avec la limite fixée... Cela me semble effectivement étonnant.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Sun, 3 Feb 2008 13:27:42 +0000 (UTC),
Vincent Lefevre <vincent+news@vinc17.org> écrivait (wrote):
Dans l'article <C3CAAF4A.C4911%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> écrit:
Le 02/02/08 22:58, dans <20080202215127$61dd@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Ce choix a quand même le gros
problème de ne pas pouvoir réagir proprement.
"proprement" ? Ce choix a l'avantage d'être dynamique et est en concordance
avec le swap qui n'utilise pas une place limitée par une partition dédiée.
Si on veut vraiment tester sous Mac OS X (ou un autre Unix) la place
retournée par malloc, il suffit de la remplir par un pattern.
Non, ça ne teste rien du tout. Ça force l'allocation, et s'il n'y a pas
assez de mémoire, le programme plante!
Le manuel de malloc (sur MacOS X) évoque la variable d'environnement
'MallocPreScribble' pour préremplir l'espace alloué par 0xaa.
De plus, que la mémoire soit allouée immédiatement ou de manière
paresseusse, le fait que 'malloc' retourne un pointeur et que errno ne
soit pas positionné à ENOMEM devrait quand même indiqué que la mémoire
est potentiellement allouable. Ce qui est pourtant en contradiction
avec la limite fixée... Cela me semble effectivement étonnant.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Sun, 3 Feb 2008 13:27:42 +0000 (UTC), Vincent Lefevre <vincent+ écrivait (wrote):
Dans l'article <C3CAAF4A.C4911%, Eric Levenez écrit:
Le 02/02/08 22:58, dans <20080202215127$, « Vincent Lefevre » <vincent+ a écrit :
Ce choix a quand même le gros problème de ne pas pouvoir réagir proprement.
"proprement" ? Ce choix a l'avantage d'être dynamique et est en concordance avec le swap qui n'utilise pas une place limitée par une partition dédiée. Si on veut vraiment tester sous Mac OS X (ou un autre Unix) la place retournée par malloc, il suffit de la remplir par un pattern.
Non, ça ne teste rien du tout. Ça force l'allocation, et s'il n'y a pas assez de mémoire, le programme plante!
Le manuel de malloc (sur MacOS X) évoque la variable d'environnement 'MallocPreScribble' pour préremplir l'espace alloué par 0xaa.
De plus, que la mémoire soit allouée immédiatement ou de manière paresseusse, le fait que 'malloc' retourne un pointeur et que errno ne soit pas positionné à ENOMEM devrait quand même indiqué que la mémoire est potentiellement allouable. Ce qui est pourtant en contradiction avec la limite fixée... Cela me semble effectivement étonnant.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Eric Levenez
Le 04/02/08 15:41, dans <20080204143539$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C3CBCD23.C49B8%, Eric Levenez écrit:
Le 03/02/08 14:27, dans <20080203132306$, « Vincent Lefevre » <vincent+ a écrit :
Non, ça ne teste rien du tout. Ça force l'allocation, et s'il n'y a pas assez de mémoire, le programme plante!
Il faut bien sûr trapper les signaux.
Mais le signal en question (s'il est trappable)
Bien sûr qu'il est trappable. Il n'y a que KILL et STOP qui ne le sont pas.
n'est pas défini de manière portable.
Posix n'est pas standard ?
Et comme tu le dis ci-dessous:
De toute façon, si le programme Linux alloue trop de place, et même si cela semble marcher du point de vue du malloc, le noyau peut très bien tuer celui qui a osé allouer toute cette ram, et cela dans la microseconde qui suit.
C'est sur Linux, ici on parlais de Mac OS X qui ne se comporte pas forcément de la même façon.
Oui, mais la cause première de ce comportement anormal est bien la surallocation.
Pas forcément. Un programme peut très bien gérer sa mémoire et une série d'autres programmes peuvent rendre la machine instable.
J'imagine que quelqu'un qui a lancé un très gros programme de calcul tournant depuis plusieurs jours et qui voit son programme tué de cette manière doit être content. :)
Des solutions de reprise existent dans ce cas.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 04/02/08 15:41, dans <20080204143539$0c48@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Dans l'article <C3CBCD23.C49B8%usenet@levenez.com>,
Eric Levenez <usenet@levenez.com> écrit:
Le 03/02/08 14:27, dans <20080203132306$2d70@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Non, ça ne teste rien du tout. Ça force l'allocation, et s'il n'y a pas
assez de mémoire, le programme plante!
Il faut bien sûr trapper les signaux.
Mais le signal en question (s'il est trappable)
Bien sûr qu'il est trappable. Il n'y a que KILL et STOP qui ne le sont pas.
n'est pas défini de
manière portable.
Posix n'est pas standard ?
Et comme tu le dis ci-dessous:
De toute façon, si le programme Linux alloue trop de place, et même
si cela semble marcher du point de vue du malloc, le noyau peut très
bien tuer celui qui a osé allouer toute cette ram, et cela dans la
microseconde qui suit.
C'est sur Linux, ici on parlais de Mac OS X qui ne se comporte pas forcément
de la même façon.
Oui, mais la cause première de ce comportement anormal est bien la
surallocation.
Pas forcément. Un programme peut très bien gérer sa mémoire et une série
d'autres programmes peuvent rendre la machine instable.
J'imagine que quelqu'un qui a lancé un très gros
programme de calcul tournant depuis plusieurs jours et qui voit
son programme tué de cette manière doit être content. :)
Des solutions de reprise existent dans ce cas.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 04/02/08 15:41, dans <20080204143539$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C3CBCD23.C49B8%, Eric Levenez écrit:
Le 03/02/08 14:27, dans <20080203132306$, « Vincent Lefevre » <vincent+ a écrit :
Non, ça ne teste rien du tout. Ça force l'allocation, et s'il n'y a pas assez de mémoire, le programme plante!
Il faut bien sûr trapper les signaux.
Mais le signal en question (s'il est trappable)
Bien sûr qu'il est trappable. Il n'y a que KILL et STOP qui ne le sont pas.
n'est pas défini de manière portable.
Posix n'est pas standard ?
Et comme tu le dis ci-dessous:
De toute façon, si le programme Linux alloue trop de place, et même si cela semble marcher du point de vue du malloc, le noyau peut très bien tuer celui qui a osé allouer toute cette ram, et cela dans la microseconde qui suit.
C'est sur Linux, ici on parlais de Mac OS X qui ne se comporte pas forcément de la même façon.
Oui, mais la cause première de ce comportement anormal est bien la surallocation.
Pas forcément. Un programme peut très bien gérer sa mémoire et une série d'autres programmes peuvent rendre la machine instable.
J'imagine que quelqu'un qui a lancé un très gros programme de calcul tournant depuis plusieurs jours et qui voit son programme tué de cette manière doit être content. :)
Des solutions de reprise existent dans ce cas.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Vincent Lefevre
Dans l'article <C3CD1FA3.C4ADA%, Eric Levenez écrit:
Le 04/02/08 15:41, dans <20080204143539$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <C3CBCD23.C49B8%, Eric Levenez écrit:
Le 03/02/08 14:27, dans <20080203132306$, « Vincent Lefevre » <vincent+ a écrit :
Non, ça ne teste rien du tout. Ça force l'allocation, et s'il n'y a pas assez de mémoire, le programme plante!
Il faut bien sûr trapper les signaux.
Mais le signal en question (s'il est trappable)
Bien sûr qu'il est trappable. Il n'y a que KILL et STOP qui ne le sont pas.
Justement, le processus est parfois/souvent(?) tué par SIGKILL (en cas de surallocation, le noyau doit employer les grands moyens).
Oui, mais la cause première de ce comportement anormal est bien la surallocation.
Pas forcément. Un programme peut très bien gérer sa mémoire et une série d'autres programmes peuvent rendre la machine instable.
Dans ce cas, c'est un problème au niveau de l'OS.
J'imagine que quelqu'un qui a lancé un très gros programme de calcul tournant depuis plusieurs jours et qui voit son programme tué de cette manière doit être content. :)
Des solutions de reprise existent dans ce cas.
À condition qu'elles soient implémentées, ce qui n'est pas toujours évident. Et comme le temps de développement, de test et de débuggage coûte cher, ce n'est pas toujours fait.
Oui, mais la cause première de ce comportement anormal est bien la
surallocation.
Pas forcément. Un programme peut très bien gérer sa mémoire et une
série d'autres programmes peuvent rendre la machine instable.
Dans ce cas, c'est un problème au niveau de l'OS.
J'imagine que quelqu'un qui a lancé un très gros
programme de calcul tournant depuis plusieurs jours et qui voit
son programme tué de cette manière doit être content. :)
Des solutions de reprise existent dans ce cas.
À condition qu'elles soient implémentées, ce qui n'est pas toujours
évident. Et comme le temps de développement, de test et de débuggage
coûte cher, ce n'est pas toujours fait.
Oui, mais la cause première de ce comportement anormal est bien la surallocation.
Pas forcément. Un programme peut très bien gérer sa mémoire et une série d'autres programmes peuvent rendre la machine instable.
Dans ce cas, c'est un problème au niveau de l'OS.
J'imagine que quelqu'un qui a lancé un très gros programme de calcul tournant depuis plusieurs jours et qui voit son programme tué de cette manière doit être content. :)
Des solutions de reprise existent dans ce cas.
À condition qu'elles soient implémentées, ce qui n'est pas toujours évident. Et comme le temps de développement, de test et de débuggage coûte cher, ce n'est pas toujours fait.
Là tu parles du noyau (Linux en plus) qui tue un ou plusieurs processus pour gagner de la place mémoire. Le but étant de récupérer de la place, il paraît normal que le signal ne soit pas trappable.
Je ne sais pas si le noyau de Mac OS X tue les processus de cette façon dans le cas d'un manque de place pour un programme qui a fait un gros malloc. Je ne parle pas du cas où le système décide de tuer un processus pour gagner de la place (là aussi je ne sais pas si Mac OS X le fait et si oui comment).
Il y a des systèmes non POSIX. Par exemple, là
On parlait de Mac OS X qui est maintenant un UNIX.
http://lwn.net/Articles/104867/
il est question d'AIX avec un signal SIGDANGER.
Ceci est étonnant (mais rien ne me surprend plus sur AIX) car ce système réserve normalement la mémoire de façon stricte et il réserve _en_plus_ l'espace dans le swap disque.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 05/02/08 14:49, dans <20080205133500$57c2@prunille.vinc17.org>, « Vincent
Lefevre » <vincent+news@vinc17.org> a écrit :
Justement, le processus est parfois/souvent(?) tué par SIGKILL (en
cas de surallocation, le noyau doit employer les grands moyens).
Là tu parles du noyau (Linux en plus) qui tue un ou plusieurs processus pour
gagner de la place mémoire. Le but étant de récupérer de la place, il paraît
normal que le signal ne soit pas trappable.
Je ne sais pas si le noyau de Mac OS X tue les processus de cette façon dans
le cas d'un manque de place pour un programme qui a fait un gros malloc. Je
ne parle pas du cas où le système décide de tuer un processus pour gagner de
la place (là aussi je ne sais pas si Mac OS X le fait et si oui comment).
Il y a des systèmes non POSIX. Par exemple, là
On parlait de Mac OS X qui est maintenant un UNIX.
http://lwn.net/Articles/104867/
il est question d'AIX avec un signal SIGDANGER.
Ceci est étonnant (mais rien ne me surprend plus sur AIX) car ce système
réserve normalement la mémoire de façon stricte et il réserve _en_plus_
l'espace dans le swap disque.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Là tu parles du noyau (Linux en plus) qui tue un ou plusieurs processus pour gagner de la place mémoire. Le but étant de récupérer de la place, il paraît normal que le signal ne soit pas trappable.
Je ne sais pas si le noyau de Mac OS X tue les processus de cette façon dans le cas d'un manque de place pour un programme qui a fait un gros malloc. Je ne parle pas du cas où le système décide de tuer un processus pour gagner de la place (là aussi je ne sais pas si Mac OS X le fait et si oui comment).
Il y a des systèmes non POSIX. Par exemple, là
On parlait de Mac OS X qui est maintenant un UNIX.
http://lwn.net/Articles/104867/
il est question d'AIX avec un signal SIGDANGER.
Ceci est étonnant (mais rien ne me surprend plus sur AIX) car ce système réserve normalement la mémoire de façon stricte et il réserve _en_plus_ l'espace dans le swap disque.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Vincent Lefevre
Dans l'article <C3CE7198.C4C1F%, Eric Levenez écrit:
Le 05/02/08 14:49, dans <20080205133500$, « Vincent Lefevre » <vincent+ a écrit :
Il y a des systèmes non POSIX. Par exemple, là
On parlait de Mac OS X qui est maintenant un UNIX.
On parle de programmes portables. Les machines supportant le C ne se résument pas à Mac OS X.
