wiki upgrade with 0.9-trunk broken

[asmodai@…]

Updating my 0.9-trunk installation from September 26th to today's 14 October trunk everything goes as normal until I do a wiki upgrade.

I've rm -rf'd trac from site-packages and from /usr/local/share, installed. Trac-admin /usr/local/trac and then upgrade. No problems.

Then using wiki upgrade I get:

Trac usr/local/trac> wiki upgrade

/usr/local/share/trac/wiki-default/TracImport ⇒ TracImport

Command failed: weakly-referenced object no longer exists

SQLite 3.2.5, pysqlite 1.1.6, FreeBSD 4.11-STABLE, Python 2.4.2.

[Christian Boos]

Thanks for testing, I'll look into this.

[Christian Boos]

right now :)

[Christian Boos]

Hm, wait a minute, are you sure it's pyqslite-1.1.6? It can't be, if you're using SQLite 3.2.5, no?

Also, the pysqlite1 related code shouldn't deal with weakrefs at all…

[Matthew Good]

cboos is there some compatibility issue with newer SQLite versions and pysqlite? Pysqlite 1.1.x is made for SQLite 3, so I would think that these versions should be ok together. Although since the weakref issues are occurring it would suggest that pysqlite2 has been installed as well.

[Christian Boos]

My mistake, I thought pysqlite-1.x was for SQLite2 only, but of course, it's:

• version 1.0.x (for SQLite 2.8.x)
• version 1.1.x or 2.x (for SQLite 3.x)

Then, I was able to reproduce the issue and fix it in r2357.

The problem can be explained as follows: Before r2355, when a connection got garbage collected, it went through the __del__ method which "closed" the connection and in fact put the connection object back in the "dormant" connections list; so actually that object was kept alive.

Since r2355, we don't do that for SQLite connections anymore. Now, in pysqlite-1.1.x, a cursor has only a weakref on its connection, so a cursor could be active while its connection gets garbage collected… which is what happened here.

In pysqlite-2.x, a cursor has a real ref on its connection, thereby preventing it to be collected in situations like that.