C'est tout à fait possible. Mais comme ton code est parfaitement bien conçu, donc modulaire, tu vas pouvoir repasser tous les tests unitaires et isoler le coupable facilement...Citation:
Envoyé par |PaRa-BoL
Version imprimable
C'est tout à fait possible. Mais comme ton code est parfaitement bien conçu, donc modulaire, tu vas pouvoir repasser tous les tests unitaires et isoler le coupable facilement...Citation:
Envoyé par |PaRa-BoL
:lol: c'est une affirmation moqueuse ? :(Citation:
Envoyé par Emmanuel Delahaye
Je n'aurai pas cette prétention. Ce n'est qu'un petit projet personnel, je suis encore novice je pense avoir fait de mon mieux pour le moment :/ Mais je ne pense pas pouvoir tout reprendre à part.
En disant que je ne pensait pas avoir de pointeur NULL ou que j'avait free() tout mes buffers, je ne voulais pas dire par la que c'était bien conçu, c'est juste que j'ai vérifié 500x :/
1-je suis sceptique sur le code
si udeco retourné par seek_user_fd vaut 0 ou NULL c'est le plantage garanti.Citation:
udeco = seek_user_fd(poll_list[i].fd, ace_tables);
if (udeco != NULL && udeco->state == ALIVE) {
udeco->state = ADIED;
}
udeco=NULL et udeco->state vaut NULL donc tu ne peux pas adresser state sinon c'est le plantage garanti
2-
la synchronisation des différents événements , envoi /réception de données connection /déconnection utilisateur.Citation:
Envoyé par |PaRa-BoL
Bah non regarde je verifi dans ma condition.Citation:
si udeco retourné par seek_user_fd vaut 0 ou NULL c'est le plantage garanti.
udeco=NULL et udeco->state vaut NULL donc tu ne peux pas adresser state sinon c'est le plantage garanti
Et si udeco est NULL il essayera pas d'évaluer la deuxieme condition.Code:
2
Mon t'chat n'est pas en streaming (oui il est prevu pour un client AJAX).Citation:
la synchronisation des différents événements , envoi /réception de données connection /déconnection utilisateur.
Et quand bien même il sagirais d'un t'chat en streaming, je ne vois pas en quoi c'est génant que ca soit monothread à part des problèmes de lag.
En effet si une personne se connect il executera le code et si une personne se deconnect en même temps elle est automatiquement mise en attente avec le system poll() et vu qu'il n'ya qu'un seul thread forcement 1 seule chose à la fois donc pas de probleme de synchronisation. Enfin du moins c'est comme ca que j'imagine la chose, je vois pas autrement Oo Et à l'inverse un systeme multi thread il faut bien veillé à proteger ces données partagées (MuTeX)
Ouuups tu as raison mea culpa je m'en suis rendu compte après coup :oops: :oops:Citation:
Envoyé par |PaRa-BoL
Il n'y a pas de quoi.Citation:
Envoyé par Mat.M
Non Cette construction est tout à fait sûre, car l'évaluation se fait de gauche à droite et qu'elle cesse dès que la condition est vérifiée. C'est garanti par le langage C et c'est utilisé à outrance.Citation:
si udeco retourné par seek_user_fd vaut 0 ou NULL c'est le plantage garanti.
udeco=NULL et udeco->state vaut NULL donc tu ne peux pas adresser state sinon c'est le plantage garanti
C'est comme
Ce qui est interdit, c'est ça :Code:
2
3
4
5
6
7
Là, effectivement, si s vaut NULL, comportement indéterminé garanti.Code:
2
3
4
5
6
7
ok merci pour les précisions
Ce n'est pas que mon experience est exemplaire, mais un malloc qui echoue par manque de memoire je n'ai jamais vu ça de ma vie, c'est tellement excessivement rare comparé à la cause suivante :Citation:
Envoyé par ShootDX
Un depassement ou un double free qui corrompt certaines données internes à la libc faisant echouer aleatoirement des malloc ou des free
C'est vrai, par exemple sous linux cela n'arrive jamais puisque le processus qui a fait la demande refusée est tué. Mais c'est sous Linux...Citation:
Envoyé par Gruik
pas tout à fait correct…Citation:
Envoyé par gege2061
le programme est tué lors d'un malloc si le kernel ne peut étendre la mémoire déjà allouée au processsus…
par contre malloc peut renvoyé NULL s'il peut étendre la mémoire MAIS sans garantie que les pages puissent effectivement être allouées plus tard…
ce qui est peut être "rare"…
toutefois cela suffit à justifier de tester si malloc renvoit NULL…
la condition de rareté dépendant de l'environnement… notamment en 64 bits, les comportements risquent d'être différents…
voir (en anglais)
Pu***n, c'est gore :vomi:
Comment peut-on oser proposer ça dans un kernel qui a vocation à exclure Win32 et se répandre librement et gratuitement ?
Et à quoi sert de spécifier que malloc() est supposé retourner NULL, si c'est pour tuer un process à la place?
Personne t'empêche de le faire mieux, la GPL est faite pour ça.Citation:
Envoyé par Médinoc
lisez l'article …Citation:
Envoyé par Médinoc
et la doc de cette librairie…
vous comprendrez quand malloc() renvoit NULL et quand le processus est tué… et comment implémenter votre propre gestion de mémoire virtuelle côté "user"…
tous les OS 32 bits sont limités à un espace mémoire de 4Gb qui est partagé entre les applications et le kernel… (classiquement 3/1 pour Linux…)
donc si votre application a besoin de plus de 3Gb (en pratique 2Gb en continu est déjà un critère plus que suffisant…) soit vous passez au 64 bits, soit vous implémentez votre propre gestion de segv côté user space…
(il fut une époque - peut-être encore ? - où Photoshop le faisait…)
et Win32 n'est pas mieux loti de ce côté…
et aucun autre OS 32 bits n'ont plus d'ailleurs…
(seul Mac OS X offre une solution mais uniquement pour les programmes sans UI… ce qui signifie que pour un programme avec UI, il faut séparer le code 64 bits du code 32 bits et implémenter une IPC entre les deux pour communiquer données et résultats… ou attendre le X.5…)
mais on s'éloigne du sujet du plantage à l'origine du thread…
où les indices penchent quand même plus en faveur d'une corruption de la structure de données que d'un OOM…
Je trouve qu'un tel optimisme n'est pas professionnel, surtout au vu des conséquences.Citation:
The technical term for this is optimistic memory allocation.
Pour tout te dire, j'ignore si Win32 fait ça ou non, mais d'après les messages affichés sous XP, on dirait bien que non.
Et je trouve que ça devrait être désactivable sous Linux.
Citation:
Envoyé par Médinoc
sous Linux, c'est configurable … (Documentation/vm/overcommit-accounting)…
quant au non-professionalisme de cette technique, c'est une réflexion qui n'engage que vous…
les techniques d'allocation de type "optimiste" sont utilisées partout en informatique, du code du kernel des OS à l'allocation des locks dans les bases de données en passant par la gestion de la bande passante des réseaux…
Après quelque recherche, j'ai trouvé une description qui correspond pas mal à mon probleme :
Citation:
fandango on core
[UNIX/C hackers, from the Mexican dance] n. In C, a wild pointer that runs out of bounds, causing a {core dump}, or corrupts the `malloc(3)' {arena} in such a way as to cause mysterious failures later on, is sometimes said to have `done a fandango on core'. On low-end personal machines without an MMU, this can corrupt the OS itself, causing massive lossage. Other frenetic dances such as the rhumba, cha-cha, or watusi, may be substituted. See {aliasing bug}, {precedence lossage}, {smash the stack}, {memory leak}, {memory smash}, {overrun screw}, {core}.
À propos des allocations optimistes... c'est le principe même de la mémoire virtuelle :)
En effet, on ne limite pas la place disponible à la vraie RAM du système, et on essaie d'avoir en rAM les blocs les plus souvent utilisés. Quand il n'y a plus de place on alloue de la "fausse" RAM que l'on stocke sur le disque dur. Afin de gérer ceci au mieux il faut n'allouer que ce qui sert vraiment, et donc partir du principe qu'un processus n'utilisera pas toute la ram qu'il demande (et il y a souvent dans le code des buffers de taille totalement arbitraire, etc)
Un processus sera tué lorsque toute la mémoire (RAM et swap) est utilisée et qu'il veut en utiliser plus... ce qui pose un gros problème mais arrive très rarement (déjà sur mon pc j'ai du mal à remplir la ram...)
Ben non ce n'est pas "le principe même", puisqu'on peut très bien faire de la mémoire virtuelle sans...
La place sur le disque EST libre dans le fichier d'échange, et si un processus demande trop, on peut poliment mais fermement lui refuser plutôt que de s'adonner au surbooking et lui dire plus tard "Ah, ben non, en fait la mémoire qu'on ta promis, on en a pas, et tu ne peux même pas repartir, puisqu'on va te tuer direct!"
Là oui, si tu veux, on peut dire que l'allocation optimiste est le principe même des agences de voyages...
Si la mémoire était allouée comme les processus le demandaient, on se retrouverait très vite avec la RAM pleine et des tas d'opérations sur le disque dur pour swapper des morceaux vides ou inutilisés... disons que l'allocation optimiste ne coûte pas grand chose et aide pas mal à gérer tout ça
Pour ce qui est de tuer les processus comme ça, je pense qu'on peut dire que si la swap est remplie, c'est qu'il y a un gros souci avec la mémoire et qu'il faut de toute urgence faire de la place. Il faut bien mettre quelqu'un dehors et là, ben c'est le premier qui réclame. De toutes façons, si ce processus n'a pas eu la mémoire dont il avait besoin, je doute qu'il puisse continuer son travail normalement autrement que de signaler une erreur et/ou de réessayer, ce qui ne vas pas vraiment aider àalléger le travail du système.
De plus, l'allocation optimiste permet de gérer tout ça le mieux possible, puisque des blocs peuvent être alloués alors même qu'il n'y a de place réelle disponible nulle part.
C'est vrai que c'est un peu violent mais bon, quand y'a plus de place il faut faire le vide à tout prix ... quand on est dans un tel cas c'est que vraiment tout à été tenté avant... d'ailleurs je ne pense pas que ça se produise souvent en pratique :)