Re: "double free" segfault back in pyscopg2 2.5 - Mailing list psycopg

From Daniele Varrazzo
Subject Re: "double free" segfault back in pyscopg2 2.5
Date
Msg-id 1371750485.3159.23.camel@risotto.smithersbet.com
Whole thread Raw
In response to Re: "double free" segfault back in pyscopg2 2.5  ("Gangadharan S.A." <gangadharan@gmail.com>)
Responses Re: "double free" segfault back in pyscopg2 2.5  ("Gangadharan S.A." <gangadharan@gmail.com>)
Re: "double free" segfault back in pyscopg2 2.5  ("Gangadharan S.A." <gangadharan@gmail.com>)
List psycopg
On Thu, 2013-06-20 at 22:18 +0530, Gangadharan S.A. wrote:

> 1. We subclass the connection class and pass it in as
> connection_factory argument to psycopg2.connect() . Subclassing is
> necessary to make the garbage collector worry about this object having
> cyclic references and try tp_clear on it. This is how we end up in a
> place where the reference counting based destruction of the object on
> one thread coincides with the garbage collector trying to free the
> same object from another thread. The subclass definition of the
> connection class can simply be a "pass" statement and need not
> implement any actual functionality.

Do you mean a plain Python subclass or a C type subclass? A failed
attempt at creating connection/cursor C subclasses some times ago led me
to review the objects GC interaction (and re-introduce the bug).


> 2. We have 100s of  threads connecting to 100s of databases rationed
> out by a connection pool manager library. Connections are closed and
> opened frequently.

I guessed that was the minimum :)


> Please let me know if further information is needed.

How long have you been running 2.5 in production? Any other issue to
report that may be fixed for 2.5.1?


--
Daniele



psycopg by date:

Previous
From: "Gangadharan S.A."
Date:
Subject: Re: "double free" segfault back in pyscopg2 2.5
Next
From: "Gangadharan S.A."
Date:
Subject: Re: "double free" segfault back in pyscopg2 2.5