On 07/03/2017 04:58 AM, Craig Ringer wrote:
> On 3 July 2017 at 03:12, Andres Freund <andres@anarazel.de> wrote:
>> Hi,
>>
>> On 2017-07-02 20:58:52 +0200, Michal Novotný wrote:
>>> thank you all for your advice. I've been investigating this a little more
>>> and finally it turned out it's not a bug in libpq although I got confused
>>> by going deep as several libpq functions. The bug was really on our side
>>> after trying to use connection pointer after calling PQfinish(). The code
>>> is pretty complex so it took some time to investigate however I would like
>>> to apologize for "blaming" libpq instead of our code.
>> Usually using a tool like valgrind is quite helpful to find issues like
>> that, because it'll show you the call-stack accessing the memory and
>> *also* the call-stack that lead to the memory being freed.
> Yep, huge help.
>
> BTW, on Windows, the free tool DrMemory (now 64-bit too, yay) or
> commercial Purify work great.
Well, good to know about Windows stuff however we use Linux so that's
not a big deal. Unfortunately it's easy to miss something in valgrind if
you have once multi-threaded library linked to libpq and this
multi-threaded library is used in conjunction with another libraries
sharing some of the data among them.
Thanks once again,
Michal
--
Michal Novotny
System Development Lead
michal.novotny@greycortex.com
GREYCORTEX s.r.o.
Purkynova 127, 61200 Brno
Czech Republic
www.greycortex.com