Re: "double free" segfault back in pyscopg2 2.5
От | Daniele Varrazzo |
---|---|
Тема | Re: "double free" segfault back in pyscopg2 2.5 |
Дата | |
Msg-id | 1371750485.3159.23.camel@risotto.smithersbet.com обсуждение исходный текст |
Ответ на | Re: "double free" segfault back in pyscopg2 2.5 ("Gangadharan S.A." <gangadharan@gmail.com>) |
Ответы |
Re: "double free" segfault back in pyscopg2 2.5
Re: "double free" segfault back in pyscopg2 2.5 |
Список | 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 по дате отправления: