Vous n'êtes pas identifié(e).
Bonjour,
j'ai des fuites de mémoire dans mon programme à cause nottamment de PQisBusy :
192 bytes in 1 blocks are definitely lost in loss record 25 of 31
==26082== at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==26082== by 0x3C8340E194: PQmakeEmptyPGresult (in /usr/lib64/libpq.so.5.1)
==26082== by 0x3C83415FAC: ??? (in /usr/lib64/libpq.so.5.1)
==26082== by 0x3C8340D5AF: PQisBusy (in /usr/lib64/libpq.so.5.1)
==26082== by 0x401FC1: is_result_ready(pg_conn*) (replic.cpp:767)
==26082== by 0x404B36: build_request_in() (replic.cpp:452)
==26082== by 0x405368: main (replic.cpp:169)
la je vois un PQmakeEmptyPGresult, je ne sais pas d'où il sort, je sais qu'il n'est pas dans mon code.
J'ai pu lire sur le net que quand PQisBusy return false, postgres cree un objet PGresult, c'est lui la que je dois liberer.
Le problème est que je n y accède pas.
Hors ligne
Quand il est à false, le résultat est déjà en bonne partie traitée oui. Mais ça ne change rien, vous allez le lire, non ? Dites moi que vous ne demandez pas à votre base de données de faire du boulot pour rien 
Marc.
Hors ligne
dans mon post précédent, j'ai fait une petite bourde, je voulais dire quand BQisBusy return true.
Hors ligne
Même s'il est busy, il est possible qu'il alloue des choses, si par exemple un message entier n'est pas encore disponible. Je vous conseille, vu que vous faites du développement en C, et que vous êtes donc probablement assez à l'aise sur le sujet, de regarder directement le source : doxygen.postgresql.org est vraiment pratique.
Vous verrez que pour savoir si on est encore busy ou si les données sont arrivées, on appelle pqParseInput3, qui évidemment fait une bonne part du traitement.
Marc.
Hors ligne
je suis d'accord avec ce que vous dites, mais ma question est comment éviter la perte de mémoire.
Hors ligne
Consommer la donnée dont vous avez demandé la production ? Vous aurez votre résultat (comme décrit dans la doc: faire un PQconsumeInput, puis un autre PQisBusy et s'il retourne false, un PQgetResult)
Puis faire un PQclear dessus…
Marc.
Hors ligne
J'ai faits tout ça, mais il m'a l'aire de me dire que postgres a alloué quelque chose.
Serait-ce un Bug POSTGRES ?
Hors ligne
Probablement pas, même si ce n'est pas impossible. Cette librairie n'est pas nouvelle, et ces fonctions sont pas mal utilisées.
Attention aussi à ce que va dire un valgrind ou autre sur ce qui se passe dans la mémoire postgres… il a sa propre gestion de la mémoire, il me semble qu'elle a tendance à donner l'impression à ces outils qu'il y a des fuites.
Ne croyez pas valgrind aveuglément, vérifiez qu'il y a bien une fuite à cet endroit là.
Marc.
Hors ligne
Merci,
je penses, effectivement, que le problème vienst de Valgrind.
Je vais essayer d'utiliser un autre logiciel de détéction des fuites mémoires.
Hors ligne
que pensez vous du BUG 4578, j'ai l'impression qu'il s'agit de la même chose que ce que nous traitons ici.
Hors ligne
Le bug 4578 manque de précision. La seule conclusion donnée par Tom Lane, faute de réponse du demandeur, était un problème applicatif (donc pas un bug de PostgreSQL, mais une erreur du développeur qui a codé le client).
Guillaume.
Hors ligne
Oui, avec exactement la même chose que ce que j'ai écrite plus haut: pas de consume + clear pour libérer.
Dans le code de la libpq, c'est très clairement visible que l'appel à PQisBusy exécute la récupération des données si elles sont disponibles. Il est donc obligé d'allouer un buffer pour la recevoir.
Testez la fuite mémoire en appelant PQisBusy en boucle, déjà (en suivant bien la procédure du consume et clear), histoire de vérifier qu'en fonctionnement normal il n'y a pas de souci.
Sinon, je crois qu'il y a ou a eu des bugs dans la libc de la redhat 5 sur l'allocation de mémoire (au cas où vous seriez dans ce contexte)… je n'ai pas souvenir que ça ait été remonté ou détecté avec Postgres, mais je sais que le projet bacula, qui utilise aussi son propre allocateur de mémoire, a eu des soucis…
Marc.
Hors ligne
Sinon, je crois qu'il y a ou a eu des bugs dans la libc de la redhat 5 sur l'allocation de mémoire (au cas où vous seriez dans ce contexte)… je n'ai pas souvenir que ça ait été remonté ou détecté avec Postgres, mais je sais que le projet bacula, qui utilise aussi son propre allocateur de mémoire, a eu des soucis…
Oui, je suis dans ce contexte, malheureusement.
Hors ligne
J'ai juste un pointeur (pas trop le temps de chercher) mais je crois que c'est une conséquence de ce patch: http://sources.redhat.com/ml/libc-alpha … 00033.html
Il y a aussi ce bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=11044
Je n'ai rien trouvé dans une recherche très rapide dans leur bugzilla par contre. Je sais juste que le projet bacula a été très embêté par un bug de ce type.
De mémoire, ce n'est pas vraiment de la mémoire perdue, mais de l'allocation à la trop grosse louche ou quelque chose du genre.
Marc.
Hors ligne
Merci beaucoup
Hors ligne
