Sous Linux, si tu chopes un segfault en accédant a un NULL malloc sous Linux, tu as soit :
Tu peux nous la refaire ? C'est un peu dur à parser car tu parles de deux choses différentes à la fois: le comportement de malloc et du segfault.
IIMNM, sous linux:
malloc (en fait l'appel système brk) ne renvois jamais null, sauf si l'espace d'adresses est épuisé. malloc renvois bien null lorsque size=0 et probablement d'autres situations exceptionnelles mais il faut aller lire le code pour savoir. En pratique on peut considérer qu'il ne renvoit jamais null.
on se chope un segfault en déférençant null, sauf si on y a mappé quelque chose de manière explicite (je pense pas que l'allocateur de la glib s'amuse à faire ça dans notre dos, enfin peut-être avec les options de debug ?).
on se chope un OOM mais ça n'a aucune relation temporelle avec un malloc ou brk.Ça arrive au moment ou linux essaye d'honnorer une page-fault, soit après un dérérencement d'une adresse non encore accédée ou lors d'un swapout. Et la victime est limite tirée au sort. On dit que linux fait de l'overcommit: on peut allouer une quantité plus importante que l'espace de mémoire virtuelle (soit RAM+SWAP), il y a un problème uniquement lorsque la mémoire est utilisée... Ça j'ai entendu que windows ne le fait pas, ce qui peut être un avantage (pas de OOM...).
Bref, dans tous les cas, c'est super important de le savoir.
Care to elaborate? savoir quoi btw ? J'ai l'impression que sous linux on est foutu, on ne sait tout simplement rien faire du tout pour récupérer une situation de pénurie. Ce qui est un argument pour ceux qui ne veulent pas s'embêter avec ça... "c'est impossible à gérer alors à quoi bon s'embêter?" Un fois qu'on est au niveau zéro de la gestion, il n'est pas trop compliqué de porter sur un autre OS vu que le comportement attendu est "quelque chose plante" :P Tu peux carrément remplacer ton code par while (malloc()==NULL) processTerminate (GetRandomPid()) pour être vraiment au niveau de linux ;-)
[^] # Re: undefined behaviour
Posté par benja . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 0. Dernière modification le 27 octobre 2016 à 02:43.
Tu peux nous la refaire ? C'est un peu dur à parser car tu parles de deux choses différentes à la fois: le comportement de malloc et du segfault.
IIMNM, sous linux:
malloc (en fait l'appel système brk) ne renvois jamais null, sauf si l'espace d'adresses est épuisé. malloc renvois bien null lorsque size=0 et probablement d'autres situations exceptionnelles mais il faut aller lire le code pour savoir. En pratique on peut considérer qu'il ne renvoit jamais null.
on se chope un segfault en déférençant null, sauf si on y a mappé quelque chose de manière explicite (je pense pas que l'allocateur de la glib s'amuse à faire ça dans notre dos, enfin peut-être avec les options de debug ?).
on se chope un OOM mais ça n'a aucune relation temporelle avec un malloc ou brk.Ça arrive au moment ou linux essaye d'honnorer une page-fault, soit après un dérérencement d'une adresse non encore accédée ou lors d'un swapout. Et la victime est limite tirée au sort. On dit que linux fait de l'overcommit: on peut allouer une quantité plus importante que l'espace de mémoire virtuelle (soit RAM+SWAP), il y a un problème uniquement lorsque la mémoire est utilisée... Ça j'ai entendu que windows ne le fait pas, ce qui peut être un avantage (pas de OOM...).
Care to elaborate? savoir quoi btw ? J'ai l'impression que sous linux on est foutu, on ne sait tout simplement rien faire du tout pour récupérer une situation de pénurie. Ce qui est un argument pour ceux qui ne veulent pas s'embêter avec ça... "c'est impossible à gérer alors à quoi bon s'embêter?" Un fois qu'on est au niveau zéro de la gestion, il n'est pas trop compliqué de porter sur un autre OS vu que le comportement attendu est "quelque chose plante" :P Tu peux carrément remplacer ton code par
while (malloc()==NULL) processTerminate (GetRandomPid())pour être vraiment au niveau de linux ;-)