Re: "double free" segfault back in pyscopg2 2.5

From: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>
To: "Gangadharan S(dot)A(dot)" <gangadharan(at)gmail(dot)com>
Cc: "psycopg(at)postgresql(dot)org" <psycopg(at)postgresql(dot)org>
Subject: Re: "double free" segfault back in pyscopg2 2.5
Date: 2013-06-20 17:48:05
Message-ID: 1371750485.3159.23.camel@risotto.smithersbet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse psycopg by date

  From Date Subject
Next Message Gangadharan S.A. 2013-06-20 17:59:53 Re: "double free" segfault back in pyscopg2 2.5
Previous Message Gangadharan S.A. 2013-06-20 16:48:43 Re: "double free" segfault back in pyscopg2 2.5