Re: "double free" segfault back in pyscopg2 2.5

> Do you mean a plain Python subclass or a C type subclass?

Plain python subclass. And as I was saying, simply having a subclass
would be enough. It need not have any additional functionailty. It can
just have a "pass" statement in the subclass body. This is
demonstrated in the test script associated with the first segfault
mail thread from 4 years ago.

> How long have you been running 2.5 in production?

Nearly 2 weeks in production. The issue would show up only at
production scale and not in our test environments. Failure would have
happen roughly a couple of times per day per daemon process.

> Any other issue to
> report that may be fixed for 2.5.1?

Nothing else so far.

On 20-Jun-2013, at 11:18 PM, Daniele Varrazzo
<daniele.varrazzo@gmail.com> wrote:

> 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.
>
>
>
>
> --
> Daniele
>