Re: [HS] comportement curieux de malloc
Le Tue, 23 Apr 2013 13:10:46 +0200 Bzzz lazyvi...@gmx.com a écrit: Ça vaut largement sinon son rapport de bug, du moins une bonne question aux devs. Les arguments développés dans le fil par Erwan David et Sylvain sont corrects, rien n'est spécifié dans la doc et le cahier des charges est respecté donc ça n'est pas un bug, mais effectivement je vais peut être demander ça aux développeurs (d'un autre coté ils ont peut être autre chose à faire...) 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/20130424080407.90eb3ccee3140873d384f...@maison.homelinux.net
Re: [HS] comportement curieux de malloc
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
Re: [HS] comportement curieux de malloc
On Tue, 23 Apr 2013 08:42:05 +0200 François Boisson user.anti-s...@maison.homelinux.net wrote: 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... Ça vaut largement sinon son rapport de bug, du moins une bonne question aux devs. -- Sheer G-Lo, tu l'as trouvée ou ta femme? G-Lo Sheer: en boite Bastos tu l'as monté toi même ? -- 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/20130423131046.3eac6dce@anubis.defcon1
Re: [HS] comportement curieux de malloc
Vincent Danjean a écrit : Le 02/10/2012 09:41, BERTRAND Joël a écrit : Et comment t'assures-tu que le prochain mmap() va pouvoir se faire exactement là où tu veux (juste après le mmap() précédent) ? Le seul truc que je vois de viable, c'est la liste chaînée ou l'arbre si l'on peut vouloir accéder à un objet précis en fonction d'un champ connu. Tu peux choisir l'adresse où tu fais ton mmap (au lieu de passer NULL en premier paramètre). Certes. C'est fait assez classiquement quand on veut réserver la même plage d'adresses dans des processus différents (éventuellement sur des machines similaires mais distinctes) pour, par exemple, faire une DSM ou de la migration transparente de structures de données. Oui ? Et comment fais-tu pour t'assurer à chaque fois que tu va pouvoir rallonger ta zone mémoire sans écraser autre chose ? Soit tu fais tout à l'aide de mmap() quitte à réécrire un allocateur, soit tu réserves à l'avance la zone mémoire (et dans ce cas, je ne vois pas l'intérêt de mmap(), autant utiliser un tableau tout ce qu'il y a de plus statique). Bref, je ne vois pas en quoi utiliser mmap() te garantit de pouvoir augmenter la taille de ta zone à ta guise parce que rien ne te garantit d'avoir la place suffisante. Tu vas me dire que tu peux aussi mapper quelque chose en dehors du tas, mais ça risque fort d'un peu dépendre du système d'exploitation. Le seul truc que je vois portable, comme c'est une pile, c'est de coder ça sous forme de liste chaînée, mais ça suppose un travail de réécriture. Maintenant qu'il y a de la randomisation par défaut pour l'espace d'adressage, il doit probablement falloir regarder un peu /proc/self/maps pour choisir le lieu où faire le mmap. Même beaucoup :-P Sur mes ordis, je désactive toujours cette randomisation : je programme et c'est impossible de débogguer avec gdb si les adresses changent d'une exécution à l'autre. Cordialement, Vincent Cordialement, JKB -- 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/506d657f.4060...@systella.fr
Re: [HS] comportement curieux de malloc
On 02/10/2012 22:50, François Boisson wrote: Le Tue, 2 Oct 2012 14:23:27 + (UTC) Tanguy Ortolo tanguy+deb...@ortolo.eu a écrit: Si la nouvelle licence est libre, et si vous êtes prêt à faire un paquet propre, vous pourriez envisager de mettre réellement Camllight dans Debian. Il serait ainsi automatiquement disponible pour toutes les architectures prises en charge par Debian et Ubuntu. Il est impossible de garantir un paquet propre avec ce bug dans la mesure où le fonctionnement dépend du comportement de malloc. Il faut d'abord le résoudre. Je vais tacher de le faire mais ça risque de prendre du temps vu que je n'en ai pas beaucoup... François Boisson Si tu as la possibilité de poster le code sur github en indiquant le problème, il pourra rapidement faire de petits... - Fabien -- 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/506be526.8030...@free.fr
Re: [HS] comportement curieux de malloc
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 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/20121003114411.b72839ea73a2193916d14...@maison.homelinux.net
Re: [HS] comportement curieux de malloc
Le 02/10/2012 15:57, François Boisson a écrit : Le script ci dessous remplit parfaitement son office pour le passage de camllight à ocaml dans les cas simple, par contre je n'ai pas vu d'incompatibilité surtout dans les épreuves des concours (la dernière épreuve de Centrale proposait même des primitives Camllight et Ocaml). Quel type d'incompatibilité il y a? C'est exactement pour les choses que tu mets dans ta liste. C'est effectivement facile de passer de Camllight à Ocaml mais, quand tu est censé donner un code Camllight correct, à cause de ces différences minimes, tu ne peux pas te contenter de le tester avec OCaml. [...] sed -e '1,$s/ prefix \([^ ]*\) / ( \1 ) /g' | \ sed -e '1,$s/copy_vect/Array.copy/g' | \ sed -e '1,$s/vect_length/Array.length/g' | \ [...] -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- 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/506c9627.6060...@free.fr
Re: [HS] comportement curieux de malloc
Le 02/10/2012 09:41, BERTRAND Joël a écrit : Et comment t'assures-tu que le prochain mmap() va pouvoir se faire exactement là où tu veux (juste après le mmap() précédent) ? Le seul truc que je vois de viable, c'est la liste chaînée ou l'arbre si l'on peut vouloir accéder à un objet précis en fonction d'un champ connu. Tu peux choisir l'adresse où tu fais ton mmap (au lieu de passer NULL en premier paramètre). C'est fait assez classiquement quand on veut réserver la même plage d'adresses dans des processus différents (éventuellement sur des machines similaires mais distinctes) pour, par exemple, faire une DSM ou de la migration transparente de structures de données. Maintenant qu'il y a de la randomisation par défaut pour l'espace d'adressage, il doit probablement falloir regarder un peu /proc/self/maps pour choisir le lieu où faire le mmap. Sur mes ordis, je désactive toujours cette randomisation : je programme et c'est impossible de débogguer avec gdb si les adresses changent d'une exécution à l'autre. Cordialement, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- 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/506cb204.6040...@free.fr
Re: [HS] comportement curieux de malloc
Vincent Danjean a écrit : Le 29/09/2012 18:23, François Boisson a écrit : Le Sat, 29 Sep 2012 17:51:46 +0200 Sylvain L. Sauvagesylvain.l.sauv...@free.fr a écrit: À mon avis, c’est un gros bogue de camllight de se reposer sur un comportement non spécifié et dépendant d’une mise en œuvre particulière. 3. une fonction intermédiaire « à sommet constant » ne ferait qu’encourager les programmeurs à faire ce que semble faire camllight. Quand on se fait un tas, les objets que l’on met dedans doivent être placés _relativement_ au début du tas, en clair, on les place par des offset relatifs à heap_start, laquelle valeur doit être dans une _variable_ qui est utilisée _à chaque fois_ pour retrouver l’adresse complète de l’objet. (Et ça fonctionne que ce soit heap_start ou head_end et que l’on y place les objets en « montant » les offsets ou en les « descendant ».) Ben oui, mais ça ne fait pas mon affaire tout ça, en gros il faudrait que je refasse la gestion complète de la mémoire de camllight... Il suffit de se passer de malloc et d'utiliser plutôt mmap dans une zone libre de l'espace d'adressage, zone qu'on pourra faire grandir par le bas avec d'autres mmap quand le besoin s'en fait sentir... Et comment t'assures-tu que le prochain mmap() va pouvoir se faire exactement là où tu veux (juste après le mmap() précédent) ? Le seul truc que je vois de viable, c'est la liste chaînée ou l'arbre si l'on peut vouloir accéder à un objet précis en fonction d'un champ connu. Cordialement, JKB -- 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/506a9a94.50...@systella.fr
Re: [HS] comportement curieux de malloc
Le Tue, 02 Oct 2012 00:50:29 +0200 Vincent Danjean vdanjean...@free.fr a écrit: Ben non en fait. J'ai écrit des corrections de plusieurs problèmes de concours. Je devais les tester avec CamlLight et pas OCaml car il y a quelques petites incompatibilités. On passe très facilement d'un code CamlLight à un code OCaml (et réciproquement si on n'utilise que les choses basiques de OCaml), mais il faut quand même changer une ou deux choses. Je pourrai rechercher si vous êtes vraiment intéressés. Le script ci dessous remplit parfaitement son office pour le passage de camllight à ocaml dans les cas simple, par contre je n'ai pas vu d'incompatibilité surtout dans les épreuves des concours (la dernière épreuve de Centrale proposait même des primitives Camllight et Ocaml). Quel type d'incompatibilité il y a? François Boisson #!/bin/sh mv $1 $1.old cat $1.old | \ sed -e '1,$s/ prefix \([^ ]*\) / ( \1 ) /g' | \ sed -e '1,$s/copy_vect/Array.copy/g' | \ sed -e '1,$s/vect_length/Array.length/g' | \ sed -e '1,$s/sub_vect/Array.sub/g' | \ sed -e '1,$s/make_vect/Array.make/g' | \ sed -e '1,$s/list_length/List.length/g' | \ sed -e '1,$s/hd/List.hd/g' | \ sed -e '1,$s/tl/List.tl/g' | \ sed -e '1,$s/rev/List.rev/g' | \ sed -e '1,$s/combine/List.combine/g' | \ sed -e '1,$s/split/List.split/g' | \ sed -e '1,$s/mem/List.mem/g' | \ sed -e '1,$s/mem_assoc/List.mem_assoc/g' | \ sed -e '1,$s/string_length/String.length/g' | \ sed -e '1,$s/sub_string/String.sub/g' | \ sed -e '1,$s/rgb/Graphics.rgb/g' | \ sed -e '1,$s/unix__/Unix./g' | \ sed -e '1,$s/system__/Sys./g' | \ sed -e '1,$s/random__/Random./g' | \ sed -e '1,$s/sys__command_line/Sys.argv/g' | \ sed -e '1,$s/system_command/Sys.command/g' | \ sed -e '1,$s/make_matrix/Array.make_matrix/g' | \ sed -e '1,$s/`\(.\)`/'''\1'''/g' | \ sed -e '1,$s/make_string/String.make/g' $1 -- 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/20121002155725.5cb717696c48009f47420...@maison.homelinux.net
Re: [HS] comportement curieux de malloc
François Boisson, 2012-10-01 19:13+0200: 3) Fait un paquet source (particulièrement crade mais bon, ça marche) 4) Demandé aux développeurs (INRIA) de modifier la licence (c'est fait depuis la version 0.81) 5) Obtenu un accès cvs en R/W sur les sources Caml. Si la nouvelle licence est libre, et si vous êtes prêt à faire un paquet propre, vous pourriez envisager de mettre réellement Camllight dans Debian. Il serait ainsi automatiquement disponible pour toutes les architectures prises en charge par Debian et Ubuntu. Sinon, je ne sais pas qui décide de cela, mais il serait vraiment judicieux d'envisager de passer de Camllight à OCaml pour la prépa. Camllight est mort, par rapport à OCaml, en tout cas c'est l'impression que ça donne, ne serait-ce qu'à cause de l'absence de paquet officiel. -- ,--. : /` ) Tanguy Ortolo xmpp:tan...@ortolo.eu | `-'Debian Developer irc://irc.oftc.net/Tanguy \_ -- 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/k4etcv$ppg$1...@ger.gmane.org
Re: [HS] comportement curieux de malloc
On Tue, Oct 02, 2012 at 04:23:27PM CEST, Tanguy Ortolo tanguy+deb...@ortolo.eu said: Sinon, je ne sais pas qui décide de cela, mais il serait vraiment judicieux d'envisager de passer de Camllight à OCaml pour la prépa. Camllight est mort, par rapport à OCaml, en tout cas c'est l'impression que ça donne, ne serait-ce qu'à cause de l'absence de paquet officiel. Ça c'est du ressort de l'inspection générale de l'éducation nationale... Bonne chance -- 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/20121002143646.gw5...@rail.eu.org
Re: [HS] comportement curieux de malloc
Le Tue, 2 Oct 2012 14:23:27 + (UTC) Tanguy Ortolo tanguy+deb...@ortolo.eu a écrit: Sinon, je ne sais pas qui décide de cela, mais il serait vraiment judicieux d'envisager de passer de Camllight à OCaml pour la prépa. Camllight est mort, par rapport à OCaml, en tout cas c'est l'impression que ça donne, ne serait-ce qu'à cause de l'absence de paquet officiel. C'est que je pense. En tout cas offrir les 2... 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/20121002224128.3b009cf06e1d9f18d956e...@maison.homelinux.net
Re: [HS] comportement curieux de malloc
Le Tue, 2 Oct 2012 14:23:27 + (UTC) Tanguy Ortolo tanguy+deb...@ortolo.eu a écrit: Si la nouvelle licence est libre, et si vous êtes prêt à faire un paquet propre, vous pourriez envisager de mettre réellement Camllight dans Debian. Il serait ainsi automatiquement disponible pour toutes les architectures prises en charge par Debian et Ubuntu. Il est impossible de garantir un paquet propre avec ce bug dans la mesure où le fonctionnement dépend du comportement de malloc. Il faut d'abord le résoudre. Je vais tacher de le faire mais ça risque de prendre du temps vu que je n'en ai pas beaucoup... 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/20121002225034.25ac68998d126f4baff91...@maison.homelinux.net
Re: [HS] comportement curieux de malloc
François Boisson, 2012-09-29 15:11+0200: J'ai bien conscience du HS de ce message masi il y a sur cette liste des programmeurs avertis. Je maintiens le paquet de camllight Quel paquet de camllight ? Je ne vois rien de tel dans Debian, malheureusement. Il est utilisé en CPGE donc il faut le maintenir à flot Bof, ce qui est fait en prépa en Caml Light doit bien tourner avec OCaml non ? (par ailleurs il est 100x plus léger que ocaml). Ça c'est une bonne raison en revanche. -- ,--. : /` ) Tanguy Ortolo xmpp:tan...@ortolo.eu | `-'Debian Developer irc://irc.oftc.net/Tanguy \_ -- 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/k4ced2$d86$1...@ger.gmane.org
Re: [HS] comportement curieux de malloc
Le Mon, 1 Oct 2012 15:55:14 + (UTC) Tanguy Ortolo tanguy+deb...@ortolo.eu a écrit: François Boisson, 2012-09-29 15:11+0200: J'ai bien conscience du HS de ce message masi il y a sur cette liste des programmeurs avertis. Je maintiens le paquet de camllight Quel paquet de camllight ? Je ne vois rien de tel dans Debian, malheureusement. Si il est chez moi depuis longtemps. Initalement il n'était pas dans les dépots debian car on ne pouvait pas distribuer des binaires issus de sources modifiés. Le problème était que les sources ne compilaient pas. J'ai donc 1) Passé outre et distribué des paquets fonctionnels deb http://boisson.homeip.net/debian «distribution» divers avec «distribution» de woody à wheezy (ce qui ne me rajeunit pas) et deb http://boisson.homeip.net/ubuntu «distribution» divers avec distribution de breezy, puis dapper à precise le tout en i386 puis très rapidement i386+amd64. Ainsi le dernier paquet intègre les petites modifications faites dans le débugueur et surtout le correctif permettant de profiter pleinement de la mémoire sous 64 bits (même si ce correctif est une sous sous rustine) 2) Débuggué et transporté le code pour qu'il puisse compiler sous les libc récentes 3) Fais un paquet source (particulièrement crade mais bon, ça marche) 4) Demandé aux développeurs (INRIA) de modifier la licence (c'est fait depuis la version 0.81) 5) Obtenu un accès cvs en R/W sur les sources Caml. Il est utilisé en CPGE donc il faut le maintenir à flot Bof, ce qui est fait en prépa en Caml Light doit bien tourner avec OCaml non ? Ben oui, mais OCaml est obèse. (par ailleurs il est 100x plus léger que ocaml). Ça c'est une bonne raison en revanche. Ben oui. 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/20121001191349.95b7199f8d7764f13e739...@maison.homelinux.net
Re: [HS] comportement curieux de malloc
Le 01/10/2012 19:13, François Boisson a écrit : Le Mon, 1 Oct 2012 15:55:14 + (UTC) Tanguy Ortolo tanguy+deb...@ortolo.eu a écrit: François Boisson, 2012-09-29 15:11+0200: Il est utilisé en CPGE donc il faut le maintenir à flot Bof, ce qui est fait en prépa en Caml Light doit bien tourner avec OCaml non ? Ben oui, mais OCaml est obèse. Ben non en fait. J'ai écrit des corrections de plusieurs problèmes de concours. Je devais les tester avec CamlLight et pas OCaml car il y a quelques petites incompatibilités. On passe très facilement d'un code CamlLight à un code OCaml (et réciproquement si on n'utilise que les choses basiques de OCaml), mais il faut quand même changer une ou deux choses. Je pourrai rechercher si vous êtes vraiment intéressés. A+ Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- 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/506a1e35.7060...@free.fr
Re: [HS] comportement curieux de malloc
Le 29/09/2012 18:23, François Boisson a écrit : Le Sat, 29 Sep 2012 17:51:46 +0200 Sylvain L. Sauvage sylvain.l.sauv...@free.fr a écrit: À mon avis, c’est un gros bogue de camllight de se reposer sur un comportement non spécifié et dépendant d’une mise en œuvre particulière. 3. une fonction intermédiaire « à sommet constant » ne ferait qu’encourager les programmeurs à faire ce que semble faire camllight. Quand on se fait un tas, les objets que l’on met dedans doivent être placés _relativement_ au début du tas, en clair, on les place par des offset relatifs à heap_start, laquelle valeur doit être dans une _variable_ qui est utilisée _à chaque fois_ pour retrouver l’adresse complète de l’objet. (Et ça fonctionne que ce soit heap_start ou head_end et que l’on y place les objets en « montant » les offsets ou en les « descendant ».) Ben oui, mais ça ne fait pas mon affaire tout ça, en gros il faudrait que je refasse la gestion complète de la mémoire de camllight... Il suffit de se passer de malloc et d'utiliser plutôt mmap dans une zone libre de l'espace d'adressage, zone qu'on pourra faire grandir par le bas avec d'autres mmap quand le besoin s'en fait sentir... A+ Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- 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/506a1ef9.3020...@free.fr
Re: [HS] comportement curieux de malloc
On 29/09/12 15:11, François Boisson wrote:
Bonjour,
J'ai bien conscience du HS de ce message masi il y a sur cette liste des
programmeurs avertis.
Je maintiens le paquet de camllight et le debug au fur et à mesure (il n'était
pas libre lors de la version 0.74). Il est utilisé en CPGE donc il faut le
maintenir à flot (par ailleurs il est 100x plus léger que ocaml).
Il y a un bug curieux dans la version 64 bits:
camllight utilise une pile dynamiquement étendue vers le bas via des mallocs
judicieux. Or dans la version 64 bits, cette pile est soudainement saturée
très rapidement (trop). Qui plus est un free propre de la dernière allocation
plante le système. En fouillant, je me suis aperçu que la première allocation
n'est pas contigue des suivantes. Pour être exact voilà ce que donne la
succession d'appels de la fonction
char *xmallocverbeux(asize_t size) {
char *p;
printf(-demande de %d\n,size);
p=xmalloc(size);
printf(-0x%16x ,p);
xfree(p);
p=xmalloc(size);
printf(-0x%16x\n,p);
return(p);
}
(xmalloc étant malloc):
-0x5a768010 -0x 1bb3820
-0x 1c17a40 -0x 1c17a40
-0x 1c58aa0 -0x 1c58aa0
-0x 1d50af0 -0x 1d50af0
-0x 1d91b10 -0x 1d91b10
-0x 1dd2b30 -0x 1dd2b30
La première ligne est celle qui met le bazar, en effet sans l'appel
malloc-free-malloc (illogique) la première allocation définissnant le sommet
de
la pile puis les autres étant des augmentations successives, la pile ne peut
être étendu et bing «Out of memory» (ce qui énerve assez avec 4G de RAM)
La rustine est évidente mais je ne comprends pas ce comportement singulier au
malloc sur architecture 64 bits. Si quelqu'un a une explication/
(cela faisait plusieurs mois que je butais sur ce bug).
Merci
François Boisson
les résultats successifs de malloc n'ont aucune raison d'être contigus.
Pour agrandir une zone on le fait plutôt avec realloc, mais ça peut
aussi déplacer complètement la zone.
--
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/5066f61a.4020...@rail.eu.org
Re: [HS] comportement curieux de malloc
Le Sat, 29 Sep 2012 15:22:34 +0200 Erwan David er...@rail.eu.org a écrit: les résultats successifs de malloc n'ont aucune raison d'être contigus. Pour agrandir une zone on le fait plutôt avec realloc, mais ça peut aussi déplacer complètement la zone. J'étais en train de me pencher sur ça et me doutais d'un truc de ce genre... Le déplacement via realloc semble transparent (pas clair sur la doc), mais le problème est que visiblement ça fait une extension «par le haut» ce qui est ennuyeux, visiblement dans le source de camllight, «heap_start» est une constante à ne pas toucher. Il y a une fonction étendant la mémoire à «sommet constant»? Merci de la réponse en tout cas. François Boisson PS: Désolé du doublon, je ne comprends pas ce qui c'est pasé d'autant plus que les deux messages (identoiques) ont été envoyés à 14s d'écart, sous sylpheed, cela signifie aller le rechercher pour le réenvoyer aussi sec ce que je n'ai pas fait... -- 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/20120929155749.ef475e61e15f072480d56...@maison.homelinux.net
Re: [HS] comportement curieux de malloc
On Sat, 29 Sep 2012 15:57:49 +0200 François Boisson user.anti-s...@maison.homelinux.net wrote: clair sur la doc), mais le problème est que visiblement ça fait une extension «par le haut» ce qui est ennuyeux, visiblement dans le source de camllight, «heap_start» est une constante à ne pas toucher. Il y a une fonction étendant la mémoire à «sommet constant»? Qu'est-ce que tu entends par par le haut, une pile est une pile; après suivant qu'elle soit LIFO ou FIFO c'est la logique du niveau juste au-dessus de ton morceau de code qui détermine ça - et que les adresses de ses éléments soient croissantes ou décroissantes ou aléatoires n'a que peu d'incidence (sauf en cas de débordement du segment). -- Julien : C'est bien pratique le métro quand même thomas75 : grave thomas75 : mai il devré fair un métro entre lé ville, et pa sou terre Julien : Ca existe Julien : Ca s'appelle un train -- 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/20120929170130.5e3595b3@anubis.defcon1
Re: [HS] comportement curieux de malloc
Le Sat, 29 Sep 2012 17:01:30 +0200 Bzzz lazyvi...@gmx.com a écrit: Qu'est-ce que tu entends par par le haut, une pile est une pile; après suivant qu'elle soit LIFO ou FIFO c'est la logique du niveau juste au-dessus de ton morceau de code qui détermine ça - et que les adresses de ses éléments soient croissantes ou décroissantes ou aléatoires n'a que peu d'incidence (sauf en cas de débordement du segment). Ce n'est pas mon code, c'est le code de camllight que j'essaye de débugguer. Il y a un «heap» plaquée sur l'allocation usuelle (mais non obligatoire de malloc: Une adresse de fin de zone fixe (heap_start) et une adresse de début de zone variable (notons la heap_end), on a donc head_end heap_start. Lors d'un besoin, un malloc(taille_demandée) est fait et renvoit *généralement* et pas obligatoirement comme l'a souligné Erwan un pointeur valant head_end - taille_demandée. C'est vrai que ça marche souvent, ça marche de façon bizarre si je fais une suite malloc-free-malloc au lieu de malloc, mais c'est clair que c'est non satisfaisant. Il y a donc comme solutions * réecrire tout le bazar: avec ocaml, c'est peut être idiot * se contenter de ma rustine... bof. * essayer de voir si il y a moyen d'assurer un mécanisme faisant grossir le «heap» tel que voulu. 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/20120929174724.8ebaf3f7dd58c89a0dee6...@maison.homelinux.net
Re: [HS] comportement curieux de malloc
Le samedi 29 septembre 2012 à 15:57:49, François Boisson a écrit : Le Sat, 29 Sep 2012 15:22:34 +0200 Erwan David er...@rail.eu.org a écrit: les résultats successifs de malloc n'ont aucune raison d'être contigus. Pour agrandir une zone on le fait plutôt avec realloc, mais ça peut aussi déplacer complètement la zone. J'étais en train de me pencher sur ça et me doutais d'un truc de ce genre... Le déplacement via realloc semble transparent (pas clair sur la doc), mais le problème est que visiblement ça fait une extension «par le haut» ce qui est ennuyeux, visiblement dans le source de camllight, «heap_start» est une constante à ne pas toucher. Il y a une fonction étendant la mémoire à «sommet constant»? À mon avis, c’est un gros bogue de camllight de se reposer sur un comportement non spécifié et dépendant d’une mise en œuvre particulière. 1. malloc n’a, comme l’a dit Erwan, aucune raison d’allouer des blocs côte à côte ; 2. realloc n’a pas d’intérêt à réallouer au même endroit, d’une part parce que, justement, l’intérêt de realloc est de déplacer l’ancien bloc de façon transparente, et, d’autre part, parce que ça me ferait bien chier qu’un programme plante par manque de mémoire parce que la première allocation a été trop petite et placée dans un petit trou non extensible (ou qu’une « meilleure » place ne se soit libérée qu’après) ; 3. une fonction intermédiaire « à sommet constant » ne ferait qu’encourager les programmeurs à faire ce que semble faire camllight. Quand on se fait un tas, les objets que l’on met dedans doivent être placés _relativement_ au début du tas, en clair, on les place par des offset relatifs à heap_start, laquelle valeur doit être dans une _variable_ qui est utilisée _à chaque fois_ pour retrouver l’adresse complète de l’objet. (Et ça fonctionne que ce soit heap_start ou head_end et que l’on y place les objets en « montant » les offsets ou en les « descendant ».) Merci de la réponse en tout cas. François Boisson PS: Désolé du doublon, je ne comprends pas ce qui c'est pasé d'autant plus que les deux messages (identoiques) ont été envoyés à 14s d'écart, sous sylpheed, cela signifie aller le rechercher pour le réenvoyer aussi sec ce que je n'ai pas fait... Euh, d’après les en-têtes date, il y a 30 min et 8 s entre les deux… (c. 30 min → délai d’un spool ?) -- Sylvain Sauvage -- 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/201209291751.47105.sylvain.l.sauv...@free.fr
Re: [HS] comportement curieux de malloc
On Sat, 29 Sep 2012 17:47:24 +0200 François Boisson user.anti-s...@maison.homelinux.net wrote: lieu de malloc, mais c'est clair que c'est non satisfaisant. Il y a donc comme solutions * réecrire tout le bazar: avec ocaml, c'est peut être idiot * se contenter de ma rustine... bof. * essayer de voir si il y a moyen d'assurer un mécanisme faisant grossir le «heap» tel que voulu. Il-y-a aussi une autre possibilité, pas vraiment ergonomique ni rationnelle mais peut-être à même de fixer le PB, ça serait de définir une pile fixe [pas sur la tête!;] -- molotov Argh je m'ennuie !! Yuk T'as qu'à te faire un coktail ... -- 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/20120929175825.56ed1757@anubis.defcon1
Re: [HS] comportement curieux de malloc
Le Sat, 29 Sep 2012 17:51:46 +0200 Sylvain L. Sauvage sylvain.l.sauv...@free.fr a écrit: À mon avis, c’est un gros bogue de camllight de se reposer sur un comportement non spécifié et dépendant d’une mise en œuvre particulière. 3. une fonction intermédiaire « à sommet constant » ne ferait qu’encourager les programmeurs à faire ce que semble faire camllight. Quand on se fait un tas, les objets que l’on met dedans doivent être placés _relativement_ au début du tas, en clair, on les place par des offset relatifs à heap_start, laquelle valeur doit être dans une _variable_ qui est utilisée _à chaque fois_ pour retrouver l’adresse complète de l’objet. (Et ça fonctionne que ce soit heap_start ou head_end et que l’on y place les objets en « montant » les offsets ou en les « descendant ».) Ben oui, mais ça ne fait pas mon affaire tout ça, en gros il faudrait que je refasse la gestion complète de la mémoire de camllight... Indépendamment de tout ça, c'est tout de même étonnant que la suite malloc-free-malloc au lieu de malloc suffise à régler (ponctuellement et sur la version en cours de la libc) ce souci... François Boisson PS: Désolé du doublon, je ne comprends pas ce qui c'est pasé d'autant plus que les deux messages (identoiques) ont été envoyés à 14s d'écart, sous sylpheed, cela signifie aller le rechercher pour le réenvoyer aussi sec ce que je n'ai pas fait... Euh, d’après les en-têtes date, il y a 30 min et 8 s entre les deux… (c. 30 min → délai d’un spool ?) Ah, c'est déjà mieux, Alzheimer est une explication envisageable vus ces pbms de mémoire -- 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/20120929182342.48772ba1378bcf9d0fa18...@maison.homelinux.net
Re: [HS] comportement curieux de malloc
Le Sat, 29 Sep 2012 17:51:46 +0200 Sylvain L. Sauvage sylvain.l.sauv...@free.fr a écrit: Quand on se fait un tas, les objets que l’on met dedans doivent être placés _relativement_ au début du tas, en clair, on les place par des offset relatifs à heap_start, laquelle valeur doit être dans une _variable_ qui est utilisée _à chaque fois_ pour retrouver l’adresse complète de l’objet. (Et ça fonctionne que ce soit heap_start ou head_end et que l’on y place les objets en « montant » les offsets ou en les « descendant ».) Précision: Visiblement, le code semble tout de même faire des choses relatives aux bornes, j'ai vu des portions de codes bougeant l'ensemble (bizarrement pas lors d'une extension dynamique semble-t-il). Il ne reste donc qu'à éplucher le dit code. 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/20120929184606.79a5bc39b3c59ba063636...@maison.homelinux.net
