trac-admin initenv segfault - rev 5949

[anonymous]

when running trac-admin to initialize an environment trac segfaults.

OS : Ubuntu 7.04
ARCH : x86_64
VERSION: devel rev 5949
Database PostgreSQL 8.2

trac-admin /home/trac-repos/username initenv
Creating a new Trac environment at /home/trac-repos/username

Trac will first ask a few questions about your environment
in order to initalize and prepare the project database.

Please enter the name of your project.
This name will be used in page titles and descriptions.

Project Name [My Project]> Username Project

Please specify the connection string for the database to use.
By default, a local SQLite database is created in the environment
directory. It is also possible to use an already existing
PostgreSQL database (check the Trac documentation for the exact
connection string syntax).

Database connection string sqlite:db/trac.db>
postgres://usernametrac:password@localhost/usernametrac

Please specify the type of version control system,
By default, it will be svn.

If you don't want to use Trac with version control integration,
choose the default here and don't specify a repository directory.
in the next question.

Repository type [svn]>

Please specify the absolute path to the version control
repository, or leave it blank to use Trac without a repository.
You can also set the repository location later.

Path to repository /path/to/repos> /home/svn-repos/username/jpeltier

Creating and Initializing Project
Segmentation fault

[eblot]

This issue usually comes from the underlying libraries - libapr being the "best" candidate" although it seems that in your case the Python interpreter is killed before Trac attemps to access to the SVN repository, which might indicate an issue with another component such as the DB. Unfortunately there is little help that may come from Trac here. Search the DB and the MailingList archive as this issue is reported on a regular basis (mostly for Windows though) to see if it has already been reported for Ubuntu and whether a workaround exists. You can also try to replace PostgreSQL with SQLite to see if it helps/if the issue is tied to the PostgreSQL access.

I'd propose a wontfix here, as it's unlikely the issue comes from Trac.

[cboos]

See TracTroubleshooting about instructions for running Trac under gdb, in order to get a meaningful stack trace and the list of libraries that are used.

[anonymous]

Replying to eblot:

This issue usually comes from the underlying libraries - libapr being the "best" candidate" although it seems that in your case the Python interpreter is killed before Trac attemps to access to the SVN repository, which might indicate an issue with another component such as the DB. Unfortunately there is little help that may come from Trac here. Search the DB and the MailingList archive as this issue is reported on a regular basis (mostly for Windows though) to see if it has already been reported for Ubuntu and whether a workaround exists. You can also try to replace PostgreSQL with SQLite to see if it helps/if the issue is tied to the PostgreSQL access. I'd propose a wontfix here, as it's unlikely the issue comes from Trac.

You are correct. There seems to have been a problem with python-psycopg2 accessing the PostgreSQL database or some other underlying issue. When I switched to the python-psycopg and python-pgsql packages it worked though these packages are for older versions of PostgreSQL. Would a stack trace still be useful? Perhaps trac is triggering something?

[cboos]

Well, the stacktrace would have been useful for you in order to figure out in which library the program crashed, but you already found that it was about a python-psycopg2 vs. PostgreSQL issue. So no, we probably won't have any use of this stack trace, but if the python-psycopg2 and PostgreSQL versions you're using were actually intended to be compatible, maybe the psycopg:PsycopgTwo people would be interested to know about the problem (and the stack trace).