Le Wed, 3 Oct 2012 11:44:11 +0200 François Boisson <user.anti-s...@maison.homelinux.net> a écrit:
> > > Si tu as la possibilité de poster le code sur github en indiquant le > > problème, il pourra rapidement faire de petits... > > Bon, j'ai déposer les sources à ce jour ici avec une description du problème. > > https://github.com/FBoisson/Camllight > Pour ceux qui se rappelle de cette histoire. En fait leproblème était plus compliqué, dans ce code assez vieux, la gestion des pages du «heap» se faisait avec un tableau de longueur liée aux adresses effectives des pages en mémoire vive. Comme la libc6 s'étale dans toute la plage mémoire, cela donnait un tableau gigantesque explosant le système. Le code est rectifié. J'ai noté que sous Windows, l'allocation mémoire se limite aux adresses basses de la plage ce qui fait que ce bug ne se manifeste pas. Quel est l'intérêt important d'utiliser toute la plage mémoire? Est la possibilité de pouvoir étendre sans souci un bloc alloué? Mais dans ce cas pour faire la séquence d'attribution 1 bloc en bas de la mémoire libre, puis en bloc tout en haut puis un bloc en bas «collé» au précédent l'empêchant d'étendre le premier bloc. Si on attend un peu, on constate des allocations en haut et en bas toujours jointives. Du coup je me perd en conjectures sur la stratégie de malloc. Peut être un développeur facétieux... François Boisson -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20130423084205.e6a5c8549c212bd8714cd...@maison.homelinux.net
