IntegrityError when not logged in

[joern.zaefferer@…]

Our Trac installations at dev.jquery.com and dev.jqueryui.com throw the following error on a regular basis when the user is not logged in:

How to Reproduce

While doing a GET operation on /timeline, Trac issued an internal error.

Request parameters:

{'changeset': u'on',
 'daysback': u'30',
 'from': u'06/08/2008',
 'update': u'Update'}

System Information

Trac	0.11rc1
Python	2.4.4 (#2, Apr 26 2007, 00:02:45) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)]
setuptools	0.6c8
MySQL	server: "5.0.51a-3-log", client: "5.0.51a", thread-safe: 1
MySQLdb	1.2.2
Genshi	0.4.4
Pygments	0.9
Subversion	1.4.4 (r25188)

Python Traceback

Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/Trac-0.11rc1-py2.4.egg/trac/web/main.py", line 417, in _dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.4/site-packages/Trac-0.11rc1-py2.4.egg/trac/web/main.py", line 222, in dispatch
    req.session.save()
  File "/usr/lib/python2.4/site-packages/Trac-0.11rc1-py2.4.egg/trac/web/session.py", line 93, in save
    "VALUES(%s,%s,%s,%s)", attrs)
  File "/usr/lib/python2.4/site-packages/Trac-0.11rc1-py2.4.egg/trac/db/util.py", line 57, in executemany
    return self.cursor.executemany(sql_escape_percent(sql), args)
  File "/usr/lib/python2.4/site-packages/Trac-0.11rc1-py2.4.egg/trac/db/util.py", line 57, in executemany
    return self.cursor.executemany(sql_escape_percent(sql), args)
  File "/var/lib/python-support/python2.4/MySQLdb/cursors.py", line 218, in executemany
    r = self._query('\n'.join([query[:p], ',\n'.join(q), query[e:]]))
  File "/var/lib/python-support/python2.4/MySQLdb/cursors.py", line 312, in _query
    rowcount = self._do_query(q)
  File "/var/lib/python-support/python2.4/MySQLdb/cursors.py", line 276, in _do_query
    db.query(q)
IntegrityError: (1062, "Duplicate entry 'usd2-1-timeline.daysba' for key 1")

Ticket for that on our own installation: ​http://dev.jqueryui.com/ticket/2973

While we aren't using the most recent Trac version yet (0.11.1), there was no mention of a related change in the changelog since, nor could I find any related ticket.

[Christian Boos]

I could indeed easily reproduce the problem on your site:

IntegrityError: (1062, "Duplicate entry 'e44ec6e3f583d5e-0-timeline.daysback' for key 1")

The up-to-date system info is:

Trac	0.11.1
Python	2.4.3 (#1, May 24 2008, 13:47:28) [GCC 4.1.2 20070626 (Red Hat 4.1.2-14)]
setuptools	0.6c5
MySQL	server: "5.0.45", client: "5.0.45", thread-safe: 0
MySQLdb	1.2.2
Genshi	0.5.1
mod_python	3.2.8
Subversion	1.4.2 (r22196)

The thread-safe: 0 part could be problematic.

[Christian Boos]

Also, I've noticed in the error report pages I got this strange information:

Request parameters:
{{{
{'ctl': u'query'}
}}}

when going to ​http://dev.jqueryui.com/query, or:

{'ctl': u'timeline'}

when going to ​http://dev.jqueryui.com/timeline

Any idea what could insert this ctl parameter? Not Trac itself for sure. Maybe a plugin? Try disabling all plugins if any and see if the error persists.

[anonymous]

There are two installed plugins: TracAccountManager 0.2dev-r3554 (all components enable) and TracWebAdmin 0.1.2dev-r6060 (all components disabled).

Looks like the TracAccountManager plugin is totally outdated. I'll try to get things rolling to update that.

[joern.zaefferer@…]

Disabling all modules didn't fix the issue at all (while providing me the chance to learn editing trac.ini by hand). Other ideas?

[Christian Boos]

Replying to joern.zaefferer@…:

Other ideas?

See comment:1, the first idea was that you should fix the MySQL bindings, which were compiled in non-thread safe mode. That's a known source of problems.

A related issue is the choice of engine in MySQL. Make sure that you're using InnoDB, as MyISAM doesn't support transactions.

Please read the MySqlDb page for more information.

[Christian Boos]

This is an InstallationIssue, please at least try the advices given in comment:5. Trac does work with MySQL, when correctly set up.

If the issue persists nevertheless (i.e. with thread-safe bindings, with InnoDB as the engine for every tables), you may want to upgrade to latest 0.11.5dev (at least r8213) and activate SQL logging, to try to understand why the session information is stored twice for anonymous users.

If this ends up being a problem in Trac itself, then please reopen the ticket.