Version imprimable
Bonjour,
Savez-vous si il existe des routines qui permettent à un programme de s’allouer de la RAM au démarrage et d'ensuite travailler directement à l’intérieur de cette mémoire allouée?
J'ai recherché sur le net et j'ai rien trouvé et pourtant il me semble que c'est possible :(
Merci
malloc ?
Bonjour,
Effectivement malloc / calloc / free est la bonne réponse. C'est comme cela que l'on allouera de la mémoire vive pour notre programme (et que l'on pourra l'utiliser)
Mais, je suspecte que l'ouvreur du sujet tente de faire, ce que l'on appelle une Memory Pool (piscine de mémoire ?)
Une memory pool est une zone de mémoire que l'on alloue au début du programme (afin de faire plus d'allocation / ou d'être sur que nous avons de la mémoire) et dans laquelle nous allons piocher afin d'y mettre nos objets.
Du coup, on arrivera facilement à voir que nous aurons des problèmes de fragmentation et autre trucs de ce genre, et c'est pour cela que je vous invite à faire un tour sur google avec la memory pool en recherche.
C'est exactement ça. Mon application plante sur une machine et je suspecte un problème matériel sur la RAM. Pour éviter que mon application accède aux banc défectueux pendant l'exécution je voulais allouer la mémoire au démarrage du programme et ainsi soit mon programme plante tout de suite soit il ne plante plus (si il problème est bine là car j'en suis pas certain).
Merci LittleWhite, je vais regarder.
Si il y a un problème avec la RAM, le système risque de planter sans prévenir et non que votre application.Citation:
Envoyé par chat-pyrus
Maintenant, pour chaque appel à malloc il faut vérifié que le pointeur retourné est différent de NULL.
Je pense que vous avez fait bêtise avec vos pointeurs ... et non que la RAM est défectueuse.
Je suis d'accord, un problème de ram engendrerai des plantage machine à répétition et potentiellement au démarrage. De plus elle est souvent vérifiée par le bios au démarrage (c'est la configuration par défaut de beaucoup de cartes mères)Citation:
Envoyé par LittleWhite
Des outils type valgrind ou purify peuvent aider a trouver les problèmes de gestion mémoire dans votre application.
Ou peut être même GDB ... vu que c'est une erreur de segmentation.Citation:
Envoyé par jabbounet
Je ne pense pas que ça vienne de mon programme car il tourne très bien sur une machine identique (et sur d'autre OS aussi). J'ai un problème vraiment que sur cette machine. De plus j'ai utilisé pas mal d'outils (mudflap, bound-checking, purify, etc ...) et aucun problème n'est détecté.Citation:
Envoyé par LittleWhite
Dans le core a chaque fois le plantage ce fait sur un malloc alors qu'il y a largement ce qu'il faut au niveau de la machine et le programme est démarré à unlimited.
As tu utilisé ces outils sur cette machine précisément?Citation:
Envoyé par chat-pyrus
Le plantage à t'il lieu toujours au même endroit dans ton code?
Si le hard est identique, les librairies/OS utilisés ont probablement des configurations/versions différentes. Il va falloir jouer aux jeux des sept différences entre la machine qui marche et celle qui ne marche pas.
D'expérience et pour avoir développé des soft multi-platefomes a une certaine époque, certaines machines étaient plus tolérantes voir laxiste vis à vis de certains problèmes.
Je me souviens qu'a cette époque je ne livrais pas un soft avant de l'avoir testé sur la moins tolérante, et les problèmes que je trouvais lors de cette validation venais toujours du soft que je livrais.
Oui j'ai fait les tests directement sur la machine aussi.
Le plantage n'a pas lieu au même endroits à chaque fois et sur des threads différents.
Ce programme tourne chez pas mal de clients sans soucis, y compris sur des solaris (OS de la machine qui pose problème chez un seul client). Ce client a deux solaris quasiment identiques et l'autre ne plante pas. La seule différence et que celui qui plante est plus chargé que l'autre (avec notamment oracle dessus).
Mais ce n'est pas un problème de manque de ressources car c'est une grosse machine.
Je suis totalement d'accord avec cela. Certaines machines sont des vraies "plaies" tres sensible (surtout dans les systemes embarques :P)Citation:
Envoyé par jabbounet
Sinon, dire que c'est la machine et non le programme, je commence a trouver cela honteux. Il y a trop peu de probabilite que la memoire soit defectueuse, sachant qu'aucun autre programme ne plante sur cette machine.
des erreurs avec la memoire RAM resulte le plus souvent a des ecrans bleus ou des kernels panics.
Maintenant, j'espere que tout les retours des malloc sont verifies. Un malloc qui plante est plutot tres rare (manque de memoire, le systeme qui ne repond pas assez rapidement (?), ou d'autres truc qui arrive juste une fois dans la vie (enfin surtout maintenant que nous avons plein de memoire).
Je pense que vous allouez trop de memoire ... (plus que ce que possede la machine)
Que veut dire: "le programme est demarre a unlimited" ?
valgrind est un tres bon outil sous GNU/Linux pour la gestion de la memoire (entre autre), vous ne le citez pas.
Quel est le backtrace lorsque votre programme plante ?
Citation:
Le plantage n'a pas lieu au même endroits à chaque fois et sur des threads différents.
Cela sent tout de meme bon le manque de memoire ... ou la fuite ...Citation:
La seule différence et que celui qui plante est plus chargé que l'autre (avec notamment oracle dessus).
La charge des machines étant différente, certains problèmes liés au threading peuvent être amplifiée sur l'une des machines. le fait que tu ne le vois pas sur l'autre ne veux pas dire qu'il n'est pas présent, simplement les conditions pour que cela se produise sont moins favorables.Citation:
Envoyé par chat-pyrus
Y'a t'il des éléments communs à chaque plantages?
Quelques pistes d'investigations supplémentaires:
As-tu des données partagées par plusieurs threads?
Lors de la libération des données est-tu certains que plus aucun thread ne les utilise?
il y'a aussi la potentialité d'une section critique oubliée.
si la machine est chargée, l'OS se comporte différemment, il commence a swapper par exemple, il va scheduler les thread différemment les mettre plus souvent en attente... etc
Bonjour,
Plutôt « bassin », dans ce sens. Mais ce terme n'est pas plus usité en français. Donc…Citation:
Envoyé par LittleWhite
Si la machine en question est un PC, il existe memtest86+, en GPL, qui fonctionne au démarrage sans O.S., et qui est généralement proposé au démarrage des distributions de Linux.Citation:
=chat-pyrus;5741789]C'est exactement ça. Mon application plante sur une machine et je suspecte un problème matériel sur la RAM. Pour éviter que mon application accède aux banc défectueux pendant l'exécution je voulais allouer la mémoire au démarrage du programme et ainsi soit mon programme plante tout de suite soit il ne plante plus (si il problème est bine là car j'en suis pas certain).
j'ajouterais qu'un simple printf si l'allocation a échoué permettrait de savoir si c'est ça ou autre chose..
Là on est obligé de te croire, mais en général quand on dit "mon programme marche, c'est cette machine qui marche pas", ça peut arriver dans de très très très rares cas, mais dans 99.9999999% du temps c'est le programme qui a une erreur....
En admettant que cela soit l'allocation qui échoue, il serait bon alors de tester en partant de 1 et en augmentant le nombre de threads au fur et à mesure jusqu'à ta valeur réelle...
En tous cas, je pense qu'il y a beaucoup de tests à faire avant de dire "c'est la faute de la machine"..
Ne serait-ce que faire relire le code à quelq'un d'autre...