"double free" segfault back in pyscopg2 2.5

Hi,

It looks like the "double free" segfault from pyscopg2 2.0.8 (
http://comments.gmane.org/gmane.comp.python.db.psycopg.devel/4964 ) is back
in version 2.5:

** glibc detected *** httpd: double free or corruption (fasttop):
0x00007fb15de14180 ***

#0 0x0000003a8d232a45 in raise () from /lib64/libc.so.6
#1 0x0000003a8d234225 in abort () from /lib64/libc.so.6
#2 0x0000003a8d26fdfb in __libc_message () from /lib64/libc.so.6
#3 0x0000003a8d275716 in malloc_printerr () from /lib64/libc.so.6
#4 0x00007fee8228c3f4 in connection_dealloc (obj=0x7fee58055da0) at
psycopg/connection_type.c:1141
#5 0x00007fef12357e26 in subtype_dealloc (self=0x7fee58055da0) at
Objects/typeobject.c:1014
#6 0x00007fef1233786b in dict_dealloc (mp=0x7fee58052e10) at
Objects/dictobject.c:985
#7 0x00007fef12357e6c in subtype_dealloc (self=0x7fee880aed90) at
Objects/typeobject.c:999
#8 0x00007fef1233786b in dict_dealloc (mp=0x7fee5803a770) at
Objects/dictobject.c:985
#9 0x00007fef123d7367 in frame_dealloc (f=0x7fee580477c0) at
Objects/frameobject.c:469
#10 0x00007fef1237d0fe in fast_function (f=<value optimized out>,
throwflag=<value optimized out>) at Python/ceval.c:4109
#11 call_function (f=<value optimized out>, throwflag=<value optimized
out>) at Python/ceval.c:4042
#12 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized
out>) at Python/ceval.c:2666
#13 0x00007fef1237d0d6 in fast_function (f=<value optimized out>,
throwflag=<value optimized out>) at Python/ceval.c:4107

As before, the problem seems to be that when de-allocing the connection, we
are calling conn_close before untracking the object. conn_close allows
other threads to run and call the garbage collector, which ends up running
dealloc a second time on this object. So we free the same memory a second
time and hence the double free error.

The fix would be to call conn_close after untracking the object in
connection_type.c:connection_dealloc().

The script used to reproduce the issue back in
http://comments.gmane.org/gmane.comp.python.db.psycopg.devel/4964 will not
reproduce the issue any more because we don't rollback the in-progress
transaction during connection close anymore. The only way I reliably could
reproduce the issue in a test script was to introduce a sleep in the C code
at connection_int.c:conn_close() after Py_BEGIN_ALLOW_THREADS and then run
garbage collector from another thread during the sleep.

Thanks,
Gangadharan