Forums PostgreSQL.fr

Postgres.0

Membre

PqisBusy

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.

Marc Cousin

Membre

Re : PqisBusy

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.

Postgres.0

Membre

Re : PqisBusy

dans mon post précédent, j'ai fait une petite bourde, je voulais dire quand BQisBusy return true.

Marc Cousin

Membre

Re : PqisBusy

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.

Postgres.0

Membre

Re : PqisBusy

je suis d'accord avec ce que vous dites, mais ma question est comment éviter la perte de mémoire.

Marc Cousin

Membre

Re : PqisBusy

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.

Postgres.0

Membre

Re : PqisBusy

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 ?

Marc Cousin

Membre

Re : PqisBusy

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.

Postgres.0

Membre

Re : PqisBusy

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.

Postgres.0

Membre

Re : PqisBusy

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.

gleu

Administrateur

Re : PqisBusy

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.

Marc Cousin

Membre

Re : PqisBusy

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.

Postgres.0

Membre

Re : PqisBusy

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.

Marc Cousin

Membre

Re : PqisBusy

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.

Postgres.0

Membre

Re : PqisBusy

Merci beaucoup