09:39 <mdk> Il faudrait envoyer un mail à afpy-membres pour annocer qu'on cherche des locaux pour 2020, 2021, et qu'on cherche des volontaires sur strasbourg, que pensez-vous de : https://annuel.framapad.org/p/afpy-appel-pycon ?
09:43 <entwanne> Ça semble bien, manque peut-être juste une adresse pour savoir qui contacter
09:50 <mdk> ils peuvent répondre sur la ml membre simplement ?
09:50 <mdk> vu que ca sera envoyé la ml membres ?
09:54 <entwanne> Je pense que ça gagnerait à être explicité
10:21 <mdk> vendu !
10:22 <entwanne> hé oh, toi-même !
10:23 <mdk> comme ça ?
10:23 <entwanne> ouais c'est bien je trouve
11:56 <debnet> @mdk J'ai fait deux trois corrections mais ça me semble pas mal. ;)
12:36 <tshirtman> vstinner: si je peux profiter de ta présence dans le coin, j'essaye de trouver pourquoi notre test suite mange de la ram jusqu'a faire exploser la CI, et après avoir testé divers options, je suis sur tracemalloc/tracemallocqt maintenant, mais on est d'accord que ça trace toutes les allocations, sans indications si elles ont été correctement relachés après (et donc dispo pour les
12:36 <tshirtman> prochaines allocations de python, sans forcément redemander plus au système) ça mesure le flot, pas les fuites?
12:37 <vstinner> tshirtman: tracemalloc ne trace que ce qui passe par PyMem_RawMalloc, PyMem_Malloc, PyObject_Malloc. pas malloc ou autre
12:37 <vstinner> tshirtman: si tu regardes un diff entre deux snapshots, tracemalloc devrait te dire à quelles lignes Python regarder
12:38 <tshirtman> oui désolé du raccourcis, on utilise pas (ou pas directement) de module cpython, c'est vraiment ce que qui passe par le fonctionnement normal de la vm python qui m'intéresse, donc ça devrait suffire
12:39 <tshirtman> oui, j'ai vu les lignes et je regarde si je peux m'assurer que les resources qui sont alloués à ces lignes sont bien collectés plus tard, mais la quantité alloué n'est pas forcément indicatrice d'un problème, non? seulement si les variables utilisant cette mémoires ne sont pas collectées plus tard?
12:41 <tshirtman> (j'ai passé pas mal de temps avec objgraph a regarder ce qui pouvait fuiter, mais ça ne m'indique pas ce qui a créé ces objets, tracemalloc est sans doute un bon complément, mais il ne m'indique pas les mêmes choses donc je m'assure d'avoir compris ce que fait l'outil)
12:44 <vstinner> tshirtman: python est parfois magique. de la mémoire censés être rendue ne l'est pas pour des raisons complexes. le plus courant étant un cycle de référence
12:45 <vstinner> tshirtman: tracemalloc te dit d'où ta mémoire a été allouée. tu peux faire des diff. tracemalloc n'a pas de conscience ou d'opinion sur le conflit israélo-palestien
12:47 <vstinner> tshirtman: si tu as un leak de 1 Go et que tracemalloce te dit que la ligne 20 alloue 1 Go, bah tu sais d'où vient l'allocation :)
12:47 <vstinner> après en pratique, c'est toujours carrément plus subtile :)
12:57 <mathieui> (ça me rappelle du code sur lequel je suis tombé au boulot cette semaine, avant on avait un paquet python2 bidouillé à installer en cas de debug qui incluait tracemalloc, donc l’existence du module suffisait à activer du debug et logging supplémentaire avec un comportement particulier, mais en python 3 étrangement ça se passe moins bien é_è)
13:00 <vstinner> mathieui: j'ai implémenté tracemalloc pour python2, mais ça demande de recompiler Python. ce n'est pas lié au mode debug
13:00 <vstinner> mathieui: ou alors tu parles d'un autre outil que tracemalloc, peut être un outil qui utilis sys.getobjects() qui n'est dispo qu'en mode debug ?
13:00 <mathieui> vstinner, non, je parle du debug de notre application
13:00 <mathieui> qui conditionnait des choses à l’import réussi de tracemalloc
13:01 <vstinner> ok
14:16 <tshirtman> vstinner: merci, c'est malheureusement un peu plus complexe, chacun des tests semble fuiter un peu de mémoire, du coup, au bout d'un moment on arrive dans les 4G, c'est un peu triste pour le worker dans la CI, mais je pense que tu répond a ma question, c'est toutes les allocations, qu'elles aient été collectées ou pas, du coup ce n'est qu'une partie de ce dont j'ai besoin, la chasse continue.
14:16 <tshirtman> merci pour l'outil, et pour les réponses :)
14:17 <tshirtman> (et je suis en python2, et j'ai recompilé python pour avoir tracemalloc, c'est pas si terrible, mais ça rend moins service que j'espérait, par ce que je suis de nature optimise, j'imagine :D)
14:17 <tshirtman> )
14:18 <tshirtman> (et oui, c'est scandaleux d'être en python2 encore, ça fait partie des chantier prévus, mais il y'en a tant, on tentera la migration au prochain quarter, mais ça va être sport, et ce sera sans moi, je serais partis ailleurs, bonne chance à eux :D)
14:22 <vstinner> tshirtman: bah si dans le test 2, tu vois encore des allocations du test 1 : y'a des soucis
14:22 <tshirtman> ah, elles devraient donc avoir disparues, cool, c'est bon a savoir
14:22 <vstinner> tshirtman: j'ai déjà corrigé pas mal de bugs dans unittest qui empêchaient de libérer la mémoire entre deux tests :)
14:23 <vstinner> tshirtman: bah après ça dépend comment est conçu ton test. parfois tu as envie de garder un environnement actif entre deux tests, parce que ça prend du temps de créer cet environnement
14:23 <tshirtman> le truc c'est que pytest conserve les classes tests tout au long de la test suite, donc il faut s'assurer de retirer toute ressource allouée dans le tearDown, sinon elles durent toute la durée de vie de pytest
14:24 <tshirtman> oui, mais il y'a des trucs qu'on recrée pour chaque test, et qui semble persister, donc si tracemalloc m'affiche des +1M sur une ligne en fin de test, c'est que ce qu'a créé cette ligne, directement ou indirectement, n'a pas été libéré depuis.
14:24 <tshirtman> semblent*
14:25 <vstinner> "pytest conserve les classes tests tout au long de la test suite" c'est peut être une partie de ton problème
14:26 <vstinner> tshirtman: tracemalloc te dit ce que se passe. à toi de te creuser la tête de savoir si c'est normal ou non
14:27 <vstinner> tshirtman: c'est sûr que si chaque test alloue 100 Mo et que tout n'est libéré qu'à la fin, bon, après 40 tests, la machine commence à consommer pas mal :-D
14:27 <tshirtman> 1/ oui apparement c'est normal, c'est pour afficher les reports à la fin, d'autres gens rapportent une fuite mémoire lié à ça, mais bien plus faible que la mienne (ça fit en 2G pour 3500+ tests, alors que j'éclate 4G avec quelques centaines).
14:28 <tshirtman> 2/ oui, je veux juste être sur de bien comprendre ce que tracemalloc me dit, d'ou ma question, est-ce qu'il me dit si de la mémoire a été allouée, ou est-ce qu'il me dit que de la mémoire n'a pas été libérée? :D
14:29 <vstinner> tshirtman: bah... peut être que tu devrais te débrouiller pour qu'un "test case" conserve juste le résultat "le test passe" / "le test échoue", sans garder plein d'objets vivant en RAM
14:29 <vstinner> tshirtman: j'comprends pas (2)
14:29 <tshirtman> j'ai installé pytest-leaks et tous mes tests indique "leaks" :D
14:29 <vstinner> tshirtman: tracemalloc me montre la mémoire actuellement allouée
14:29 <tshirtman> ah super, c'est ma question
14:29 <tshirtman> a = list() # allocation
14:29 <tshirtman> del(a) # libération
14:29 <vstinner> hahahahahahahha
14:29 <vstinner> pardon
14:30 <vstinner> "del a" != libérer la mémoire
14:30 <tshirtman> (en supposant que personne d'autre ne référence)
14:30 <vstinner> mais c'est mignon de penser que c'est aussi simple
14:30 <tshirtman> ah oui, et en appelant gc.collect()
14:30 <vstinner> a=[]; a=[a]; del a # surprise
14:30 <tshirtman> oui, la il y'a une référence
14:30 <tshirtman> je sais ça
14:30 <tshirtman> je débute pas en python
14:31 <tshirtman> je suis pas aussi calé que toi, pas de soucis, mais je connais les bases quand même
14:31 <tshirtman> ma question était surtout, dans le cas idéal que j'ai décrit, que dit tracemalloc, et dans le cas que tu indique, est-ce différent
14:31 <tshirtman> ?
14:31 <nahuel> vstinner, c'est quoi la surprise ?
14:31 <vstinner> tshirtman: ce que j'essaye de dire : c'est que tu penses peut être que la mémoire est libéré, mais seul tracemalloc sait :)
14:32 <vstinner> nahuel: c'est pas forcément libéré immédiatement
14:32 <nahuel> ah, I see
14:33 <vstinner> nahuel: http://paste.alacon.org/46181 exemple avec tracemalloc
14:33 <tshirtman> vstinner: ok, je crois que ça répond a ma question, merci :)
14:33 <nahuel> ahah
14:33 <nahuel> vstinner, sympatoche
14:34 <nahuel> ça ne libère pas immédiatement, ou ça ne libère jamais ?
14:34 <vstinner> nahuel: quand t'as un cycle de référence, parfois il faut provoquer une collection du ramasse miettes, appel à gc.collect()
14:34 <tshirtman> et si t'as un __del__ quelque part, python peut dire osef, il me semble :)
14:35 <tshirtman> (dans le cas des cycles)
14:35 <vstinner> nahuel: si tu n'appelles pas gc.collect(), l'objet sera détruit "plus tard", mais en gros, c'est très compliqué de prédire quand
14:35 <vstinner> tshirtman: depuis Python 3.4, __del__ n'est pas un gros problème : https://www.python.org/dev/peps/pep-0442/
14:35 <nahuel> vstinner, là, même avec le gc.collect tu reviens pas à l'état d'origine
14:36 <vstinner> nahuel: magie ! :-D
14:36 <nahuel> vos idées ont du génie ?
14:36 <vstinner> nahuel: c'est compliqué de suivre la mémoire
14:36 <vstinner> nahuel: hahaha. c'est bon le maggie !
14:37 <vstinner> nahuel: à la fin, y'a _moins_ de mémoire. ça va !
14:37 <nahuel> ^^
14:40 <tshirtman> j'imagine que l'import des modules au startup a créé des choses collectables, et le gc n'avait pas encore tourné
14:41 <vstinner> tshirtman: gc.collect() fait plusieurs trucs pour libérer la mémoire. ça libère aussi des "free lists"