7110

Excuse moi mais si tu travaille dans un environnement un tant soit peu sérieux tu as des outils comme l'analyse statique ou équivalent (lint pour du C est suffisant pour ça par exemple) qui veille au grain pour ce genre de choses.

C'est le genre de test BASIQUE qui soit être systématiquement fait.

Je n'ai, a vrai dire, jamais vu du code de PRODUCTION, qui ne fasse pas ce genre de test. Dans du code reservé a a faire des test a la limite, mais en prod non.

C'est avec ce genre de pratiques/phrases qu'on se trouve avec des heartbleed. (meme si la ce n'est pas lie a un pointeur null)

beaucoup de bugs sont lié a une gestion de la memoire calamiteuse, donc oui un soft qui ne fait pas de test basique (meme un simple ASSERT(ptr != NULL); est suffisant, brutal mais suffisant) ne peux PAS etre mis en prod sans enorme risque.

D'ailleurs meme avec l'overcommit malloc peux quand meme répondre NULL sous linux. (sous une version 32bit essaye d'allouer plus de 3Go au total tu va voir..)


Et si vraiment tu as la FLEMME de faire toi meme pour chaque allocation, tu fait une fonction genre

void *safe_alloc(size_t sz) { void *ptr = calloc(sz); ASSERT(ptr != NULL); return ptr; }
Et ne fait plus appeil a malloc directement mais a safe_alloc.

Un pointeur null + dereferencement, au meilleurs des cas on a un segfault. Sauf si on a une operation de type (pointer + X) et la.. on va potentiellement lire de la memoire si elle est alloué dans la MMU.

Donc tu fait comme tu veux, mais une app qui ne gere pas la memoire correctement n'a absolument rien a faire en production.

Donc non assumer que malloc ne retourne JAMAIS une erreur est un probleme, Et non j’espère vraiment que la "quasi-totalité des programmes utilisés sur n'importe quelle plate-forme de production ne teste jamais la réussite des appels à malloc" parce qu'on aurais vraiment pas mal d'emmerdes a cause de ca, et je peux t'assurer que tout code un tant soit peu serieux (et qui doit l'etre) qui me soit passé dans les main ne part pas du principe que malloc ne retourne jamais une erreur, c'est meme plutot le contraire, il faut TOUJOURS assumer que tout peux foirer


edit: un exemple de ce dont je veux parler sur le fait que c'est une faille potentielle:
#include <stdio.h> #include <stdint.h> int main() { char *ptr = NULL; char ascii[] = "Hello World"; uint64_t depl = (uint64_t)&ascii[0]; printf("ptr = %p\n", ptr); printf("ptr[depl] = %p\n", &ptr[depl]); printf("ascii = %p\n", &ascii[0]); printf("%s\n", &ptr[depl]); return 0; }
Ce code marche sans probleme:

ubuntu@ubuntu-armhf:~$ ./test 
ptr       = (nil)
ptr[depl] = 0xbec32b90
ascii     = 0xbec32b90
Hello World

Suivant ce que fait le code, un malloc foireux peux etre exploité pour acceder a de la memoire, c'est une faille de securite au meme titre que ne pas verifier ta requete SQL ou faire un eval($_GET['bla']) ou include($_GET['bla']) en PHP.

Au contraire tout projet serieux fait super attention a l'allcoation memoire, exemple:

https://www.nginx.com/resources/wiki/extending/api/alloc/#ngx-alloc
utilisaton: https://github.com/nginx/nginx/blob/0f89206a1078a216961d974ed5bcf6464b65cbdf/src/event/modules/ngx_devpoll_module.c#L151

Apache fait un abort en cas d'erreur d'allocation:
https://github.com/apache/httpd/blob/f3a50c0902efd798f80c6b86290e0bddf26b2843/server/util.c#L3109
(ap_abort on oom: https://github.com/apache/httpd/blob/f3a50c0902efd798f80c6b86290e0bddf26b2843/server/util.c#L3093 )

Si tu trouve un application qui est fait pour de la production et qui ne gère pas l'allocation mémoire correctement c'est un bug report direct !
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

7111

Zeph (./7109) :
C'est un peu rapide comme verdict. Même si en théorie c'est vrai, tu sais très bien que la quasi-totalité des programmes utilisés sur n'importe quelle plate-forme de production ne teste jamais la réussite des appels à malloc. C'est triste mais c'est un fait, et à partir de là si ta solution consiste à dire "tous les programmes du monde sont buggés et il faut les réécrire", ça n'est pas très crédible.
epee

accessoirement, c'est simple à tester en C (mais particulièrement pénible), mais dans d'autres langages un peu plus haut niveau (qui ne te donnent pas accès aux allocations mémoire), ça revient à faire des try/catch sur chaque ligne de code #couic
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

7112

./7110 : tu réponds à côté de la plaque, je ne te dis pas que c'est une bonne chose de ne pas vérifier les accès mémoire ou que c'est compliqué à faire, je te dis simplement qu'en pratique une large majorité de projets ne le font pas. Ça ne sert à rien de se mettre la tête sans le sable et expliquer que "ces programmes ne devraient pas exister" pour résoudre le problème.

./7111 : pencil, et quand on utilise ces langages plus haut niveau qui vont jeter des exceptions, tout comme les wrappers qui ajoutent un assert automatique sur le résultat de malloc, ne vont faire qu'ajouter un peu de contexte dans les stack traces mais en aucun cas rendre le programme plus fiable. Il plantera dans tous les cas, à moins de gérer tous les échecs possibles proprement, ce qui n'est en pratique jamais fait.
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

7113

Mais tu ne fait pas d'allocation mémoire avec tes langages de plus haut niveau, c'est ton langage qui fait ce genre de tests pour toi !

Tu ne fait pas d'allocation mémoire en python, (en je ne compte pas le C++ dans les haut niveau parce que est la même chose que le C, si un new n'est pas systématiquement vérifié c'est un bug dans l'app.)
En Java je sèche, mais de mémoire c'est la JVM qui fait les vérifications a ta place et les vérifie, on a pas de notion de pointeurs.

A partir du moment ou tu fait l'allocation a la main comme en C ou C++ tu DOIT verrier que l'allocation c'est bien passée.

Dans tous langage ou la gestion de la mémoire t'es caché bien sur que tu ne fait aucune vérification directe, si il y a une erreur de mémoire tu va te manger une exception, si tu ne la traite pas c'est ton problème, mais ça ne provoquera probablement pas un faille de sécurité potentiellement béante.

Edit:
Si tu as un wrapper autour de malloc, meme si il fait un simple assert, ta phrase "tu sais très bien que la quasi-totalité des programmes utilisés sur n'importe quelle plate-forme de production ne teste jamais la réussite des appels à malloc" est incorrecte, un simple assert(ptr != NULL) EST un test de la reussite de l'appel a malloc.
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

7114

bin oui, mais ça ne change pas grand chose si tu n'as pas la main sur les allocations ; soit l'appel à machin() fonctionne (entre autres parce qu'il y a assez de mémoire), soit il ne fonctionne pas (pour plein de raisons, dont l'absence de mémoire).
Sauf qu'il y a énormément d'appels qui ne peuvent pas planter (sauf cas dégénérés comme l'absence de mémoire, justement), donc tu ne vérifies pas le résultat (genre toto = "titi"). Vérifier chaque appel reviendrait à faire un try/catch à chaque ligne de code, ce qui n'a absolument aucun sens.
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

7115

Sauf que quand on parle de malloc on ne parle pas de python.. mais soit

Bien sur dans un langage tel que python ou autre interprété on ne fait pas ce genre de test, car c'est ton environemetn qui le fait pour toi.

Si on parle de malloc on parle de langage ou c'est l'application qui fait la gestion de la mémoire, et non son environement d’exécution.
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

7116

mais ça revient au même : le programme fait un appel (du code python, bien sûr, mais qui fait un malloc sous le capot) qui peut échouer (même une déclaration de variable ma_variable = "ma string") et dont le résultat n'est pas testé par le programme (même si le malloc est testé).
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

7117

Pour le TL;DR:

Zeph si tu veux dire que les apps ne font pas des choses super compliqué pour gérer les cas d'allocation défaillante et quitter "gracieusement" (i.e. pas a coup d'abort ou assert), on est d'accord. cf le cas d'Apache. Il y a des cas ou faire un chemin de sortie "propre" est compliqué voir impossible.
Mais affirmer que la majorité des applications ne vérifient pas le retour de malloc est incorrect, un simple assert est une verification.

Le pas TL;DR

Non ca ne reviens pas au meme.

On ne peux pas comparer la gestion memoire d'un langage ou celle ci est automatique avec un language ou elle est manuelle.

Et parler de malloc est clairement parler d'un language manuel.
Python en interne vérifie que ses mallocs ne retourne pas NULL, mais toi programmeur Python ce n'est pas ton problème, tu ne sais meme pas ce qu'est un pointeur, et a peine ce qu'est de l'allocation mémoire.
Toi programmeur C, si tu appel malloc et tu ne vérifie pas que le pointeur est NULL, tu fais du mauvais code, c'est ton role de verifier que ce que tu fais et valide, et donc de verifier que malloc ne te retourne pas NULL.

Planter d'une manière controllé (appel a abort, assert, chaine complete pour retourner l'erreur et quitté "normalement" et non brutalement l'app) ou laisser l'app planter n'est pas semblable du tout.

Pour reprendre l'exemple de python, tu va te manger une exception de type "MemoryError" mais encore la la semantique est differente de celle de malloc, ou plutot, python verifie que son allocation en interne est possible et/ou qu'elle n'a pas foiré, et si elle foire il genere l'exception, mais si tu ne la catch pas ton app va stopper de maniere controllée, ca ne va pas planter au prochain acces mémoire sur le dit objet.

assert((ptr = malloc(10)) != NULL)
ptr[0] = 1;
est fondamentalement different de

ptr = returning_null_malloc(10);
ptr[0] = 1;

meme si l'arrêt est brutal.
Dans le premier cas tu est certains que l'app s'arrête si le pointeur est NULL, dans l'autre; si et seulement si 0 + déplacement ne tombe pas sur un emplacement mémoire alloué dans l'espace memoire de l'application.

Mon propos est, et je répète, dans tout langage a gestion manuelle de la mémoire tel que le C ou le C++; ne pas verifier que l'allocation ne foire pas d'une manière ou d'une autre est un bug parce que tu va planter de manière non contrôlée ou pire modifier de la mémoire que tu ne doit pas toucher.

C'est comme ca que dans les systèmes sans MMU on a des plantage a la con, pointeurs bancals, qui ne pointent pas au bon endroit ou allocation non vérifié, et on se retrouve a modifier la mémoire d'un autre process, voir pire de l'OS et la bonjour les dégâts... :/
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

7118

Si un malloc échoue, le système est bon pour un reboot de toute façon non ?
avatar

7119

Pourquoi devoir forcément rebooter ? Tu peux aussi fermer un autre process qui consomme beaucoup de mémoire (ou le tuer s'il est planté) pour faire de la place.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

7120

qu'est ce qui prouve que les applis système n'a pas eu aussi besoin de mémoire et n'a pas pu faire ces traitements ?
avatar

7121

Les logs d'erreur ?
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

7122

Godzil (./7117) :
Pour le TL;DR:

Zeph si tu veux dire que les apps ne font pas des choses super compliqué pour gérer les cas d'allocation défaillante et quitter "gracieusement" (i.e. pas a coup d'abort ou assert), on est d'accord. cf le cas d'Apache. Il y a des cas ou faire un chemin de sortie "propre" est compliqué voir impossible.
Mais affirmer que la majorité des applications ne vérifient pas le retour de malloc est incorrect, un simple assert est une verification.

Le pas TL;DR

Non ca ne reviens pas au meme.

On ne peux pas comparer la gestion memoire d'un langage ou celle ci est automatique avec un language ou elle est manuelle.

Et parler de malloc est clairement parler d'un language manuel.
Python en interne vérifie que ses mallocs ne retourne pas NULL, mais toi programmeur Python ce n'est pas ton problème, tu ne sais meme pas ce qu'est un pointeur, et a peine ce qu'est de l'allocation mémoire.
Toi programmeur C, si tu appel malloc et tu ne vérifie pas que le pointeur est NULL, tu fais du mauvais code, c'est ton role de verifier que ce que tu fais et valide, et donc de verifier que malloc ne te retourne pas NULL.

Planter d'une manière controllé (appel a abort, assert, chaine complete pour retourner l'erreur et quitté "normalement" et non brutalement l'app) ou laisser l'app planter n'est pas semblable du tout.

Pour reprendre l'exemple de python, tu va te manger une exception de type "MemoryError" mais encore la la semantique est differente de celle de malloc, ou plutot, python verifie que son allocation en interne est possible et/ou qu'elle n'a pas foiré, et si elle foire il genere l'exception, mais si tu ne la catch pas ton app va stopper de maniere controllée, ca ne va pas planter au prochain acces mémoire sur le dit objet.

assert((ptr = malloc(10)) != NULL)
ptr[0] = 1;
est fondamentalement different de

ptr = returning_null_malloc(10);
ptr[0] = 1;

meme si l'arrêt est brutal.
Dans le premier cas tu est certains que l'app s'arrête si le pointeur est NULL, dans l'autre; si et seulement si 0 + déplacement ne tombe pas sur un emplacement mémoire alloué dans l'espace memoire de l'application.

Mon propos est, et je répète, dans tout langage a gestion manuelle de la mémoire tel que le C ou le C++; ne pas verifier que l'allocation ne foire pas d'une manière ou d'une autre est un bug parce que tu va planter de manière non contrôlée ou pire modifier de la mémoire que tu ne doit pas toucher.

C'est comme ca que dans les systèmes sans MMU on a des plantage a la con, pointeurs bancals, qui ne pointent pas au bon endroit ou allocation non vérifié, et on se retrouve a modifier la mémoire d'un autre process, voir pire de l'OS et la bonjour les dégâts... :/
si ce que tu dis est vrai, c'est un putain d'atout pour l'info indus... en info de gestion, j'ai vu des applis (critiques) où pas un seul free n'était fait, alors de là à gérer proprement le ko d'un malloc... et les développeurs n'ont plus le temps de développer propre... "faut shipper du code !" aujourd'hui...
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

7123

vince (./7122) :
"faut shipper du code !" aujourd'hui...
chante C'est l'histoire de ma vie
Une recompil' éternelle
Qu'un process fini, rend virtuelle chante
avatar
ROM ne s'est pas compilé en un jour

7124

Godzil (./7117) :
ok, je vois ce que tu veux dire ^^
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

7125

Godzil (./7117) :
Mais affirmer que la majorité des applications ne vérifient pas le retour de malloc est incorrect, un simple assert est une verification.
Quelle est la différence que tu veux mettre en avant ? Ton propos, en ./7108, était que toutes les applications devraient "tester si malloc retourne NULL" mais tu n'as pas expliqué l'objectif que tu cherches à atteindre.

En C, un échec d'allocation est signalé par un retour de NULL que tu es supposé vérifier. Si tu oublies de le faire, soit ton application va se mettre à avoir un comportement totalement imprévisible, soit -plus probable- elle va planter immédiatement après en essayant de déréférencer un pointeur nul. En C++, un échec d'allocation sera signalé par l'un des opérateurs "new" en jetant une exception que personne ne pense jamais à attraper, il en résulte le plus souvent un plantage immédiat de l'application. En Python, Java, C# ou dans toute une autre tripotée de langages à mémoire managée, un échec d'allocation sera signalé par une exception système qu'il est recommandé de ne pas intercepter, il en résulte là encore un plantage immédiat de l'application.

Je passe sur les détails de log, de dumps ou de contexte qui peuvent expliquer comment c'est arrivé, le résultat est le même : on a une application qui a été interrompue en plein milieu de son exécution et tous ses effets de bords n'ont pas été nettoyés correctement. On a des fichiers à moitié écrits, des données qui trainent dans des dossiers temporaires ou des /var/machin, des changements qui n'ont pas été sauvegardés, etc. Dans aucun cas c'est un comportement souhaitable et je ne vois pas trop ce que le langage qui est derrière vient changer ici. Donc pour moi, non, ajouter un assert(malloc() != null) ne change rien au problème, on y gagne peut-être quelques infos de debug mais l'application n'est pas devenue plus robuste pour autant.

La seule façon de gérer le manque de mémoire aurait été de continuer l'exécution en se passant de la mémoire qui n'a pas pu être obtenue. Bien sûr que c'est possible, mais en-dehors d'applications critiques personne ne fait ça aujourd'hui. C'est dommage, c'est de la fainéantise ou tout ce que tu veux mais c'est comme ça. Et c'est une situation qui me semble tellement impossible à réfuter que je m'épargne des liens, je pense qu'une simple recherche sur "malloc" ou "new" dans des projets GitHub connu sera une illustration suffisante de l'état de l'art dans ce domaine.
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

7126

Vu que le code que l'on écrit provient en général de stackoverflow, il est robuste car relu et corrigé par des pairs. Après si on copie/colle du vieux code posix avec des noms de fonctions de 4 lettres ou des noms de variables de 1 lettre, rajouter un test va alourdir considérablement le code. Et on dépassera la deadline. De toute façon si ça plante, c'est la faute de l'utilisateur, il suffira de lui demander d'ajouter de la mémoire.
avatar
ROM ne s'est pas compilé en un jour

7127

C'est dommage, c'est de la fainéantise ou tout ce que tu veux mais c'est comme ça.
C'est une aussi une allocation pertinente de son temps de travail grin
Si on doit vérifier de façon propre tous les cas d'erreurs improbables et prendre des décisions intelligentes à chaque fois (savoir quel fichier on doit fermer, quel message afficher, etc.), on peut supposer que ça va multiplier au moins par dix le temps de développement (estimation bien sûr particulièrement précise et fiable tripo). Beaucoup de gens vont préférer avoir de nouvelles fonctionnalités plutôt qu'un crash un peu bizarre par an ^^
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

7128

Oui, c'est pas faux. En entreprise je n'ai jamais vu la moindre vérification d'allocation, quel que soit le langage utilisé, et je ne pense pas ce soit juste parce que je suis mal tombé.
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

7129

Le jour ou ton appli critique sert de passerelle pour un hack ou autre, on en reparle ok?

abort/assert empêchera ca d'arriver quoi qu'il se passe.
Laisser pisser le NULL a de bonne chances de pouvoir être exploité d'une maniere ou d'une autre, surtout si c'est lié au domaine du web...

Je te conseille de t'interesser au hacking, jailbreaking & autre, tu verra a quel point ce genre de mauvaises pratique est une manne pour eux...

Oui arrêter une app avec un abort est brutal (enfin un OS potable, la mémoire alloué sera proprement nettoyé, fichier fermé (et normalement buffer au niveau système vidé avant etc..) oui c'est brutal, mais ce n'est pas exploitable en tant que faille. Un pointeur NULL qui traîne est une faille qui peux très vite devenir un CVE si c'est exploitable. NULL est une address mémoire comme une autre, ce qui fait planer c'est que traditionnellement l'adresse 0 est marqué comme a ne pas utiliser, mais a part ca NULL[1] n'est plus l'addresse 0 et elle peux être valide suivant le contexte dans lequel tu tourne, et modifier de la mémoire "valide" et continuer a tourner est bien pire que de stopper brutalement.
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

7130

Tu continues exactement dans la même direction, à croire que tu ne lis pas mes messages. Je propose d'arrêter la discussion ici.

[edit] Tu viens de modifier ton message et de poursuivre la même discussion sur sécurité. J'ai noté ce point, pas besoin de poster du code pour m'expliquer ce que c'est une violation d'accès, je pense comprendre à peu près de quoi il s'agit. Mais je me répète une dernière fois : c'est comme ça que ça fonctionne dans le monde réel dans lequel tu vis. À partir de là, ta phrase "tout code qui ne teste pas si il retourne NULL n'est pas du code qu'on peu mettre en production" me semble totalement déconnectée de la réalité : tu proposes de faire quoi concrètement ?
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

7131

Godzil (./7108) :
Oui enfin si tu fork un process qui a 500Mo d'alloué c'est que tu as un problème de conception dans ton app... :/ ( ou que tu devrait utiliser des Thread.
Le problème, c'est que les APIs qui lancent un processus font un fork+exec en interne, donc si tu n'overcommittes pas, tu es obligé d'allouer ces 500 Mo même si le prochain syscall sera un exec qui les libèrera immédiatement.

Godzil (./7113) :
Tu ne fait pas d'allocation mémoire en python, (en je ne compte pas le C++ dans les haut niveau parce que est la même chose que le C, si un new n'est pas systématiquement vérifié c'est un bug dans l'app.)
En C++, new lance par défaut une exception std::bad_alloc si l'allocation échoue. Il ne peut renvoyer nullptr que si tu utilises new(nothrow) ou si tu compiles avec un flag non-standard comme -fno-exceptions.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

7132

Zerosquare (./7107) :
Godzil > je considère l'overcommit comme un bug fondamental (on a déjà discuté du sujet), mais sous Linux ça me paraît difficile de s'en passer.

L'origine, c'est fork(). Sans overcommit, ça veut dire que si tu forkes un process qui a alloué 500 Mo (par exemple), tu te retrouves à devoir allouer 500 Mo pour le nouveau process, juste au cas où celui-ci modifierait toute la mémoire allouée (même si ça a peu de chances de se produire).

Or comme fork() est justement massivement utilisé sous Linux, à moins d'être prêt à rajouter plein de barrettes de RAM "au cas où", je ne vois pas trop de solutions.
Ca justement je ne comprends pas. Pourquoi tu ne pourrais pas faire de l'overcommit à la Windows, dans le swapfile ? Si une copie mémoire a peu de chances de se produire (ex. d'un fork) elle sera compressée et dégagée lorsque la mémoire sera remplie. Et si elle finit par arriver quand même ça fera une erreur de pagination et on remettra le bouzin en RAM. OK on a besoin de plus de swap avec ça, mais on n'a pas de situation d'overcommit ni besoin d'OOM killer.
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

7133

Le CoW est de l'overcommit, et c'est magnifique de faire planter une appli sans raisons apparentes parce que plus de mémoire d'une manière quel appli ne peux pas controller :/
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

7134

Brunni (./7132) :
Ca justement je ne comprends pas. Pourquoi tu ne pourrais pas faire de l'overcommit à la Windows, dans le swapfile ? Si une copie mémoire a peu de chances de se produire (ex. d'un fork) elle sera compressée et dégagée lorsque la mémoire sera remplie. Et si elle finit par arriver quand même ça fera une erreur de pagination et on remettra le bouzin en RAM. OK on a besoin de plus de swap avec ça, mais on n'a pas de situation d'overcommit ni besoin d'OOM killer.
Parce que l'écriture dans le swap est lente, ça bloque tout. Une copie virtuelle en CoW (c'est-à-dire que la copie réelle n'est effectuée qu'à l'écriture, s'il y en a une) est instantanée.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

7135

Non elle n'est pas instantanée, tu as besoin de creer toutes les tables, voir juste de les copier, ce n'est pas "instantané"
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

7136

Euh Kevin l'écriture dans la swap n'a pas besoin d'être synchrone, en plus elle n'est pas faite immédiatement. Juste la page peut rapidement être mise sur la liste de celles qui n'ont rien à faire en RAM, et la copie sur le disque sera rapide car la page n'est pas associée à des données réelles (donc elle se compresse bien, enfin si je comprends bien leur système ; mais maintenant j'ai un doute de s'il est nécessaire de faire une copie quand tu l'écris sur le disque).
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

7137

dans les linux modernes c'est pas juste l'adresse zéro qui segfault, c'est au moins la première page ou les 64 premiers k de l'address space...

quant aux exploits qui touchent la heap, "on" préfère en général bidouiller les headers de blocs avec de l'use-after-free qu'espérer des malloc() qui retournent NULL, parce que justement c'est pas trop certain qu'il retourne null grin

7138

Brunni (./7136) :
Euh Kevin l'écriture dans la swap n'a pas besoin d'être synchrone, en plus elle n'est pas faite immédiatement. Juste la page peut rapidement être mise sur la liste de celles qui n'ont rien à faire en RAM, et la copie sur le disque sera rapide car la page n'est pas associée à des données réelles (donc elle se compresse bien, enfin si je comprends bien leur système ; mais maintenant j'ai un doute de s'il est nécessaire de faire une copie quand tu l'écris sur le disque).
Si tu ne fais pas de copy-on-write, pour un fork, l'écriture doit être synchrone, ou alors tu dois faire une copie en RAM en attendant qu'elle soit déplacée vers la swap.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

7139

avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

7140

ouch :/