Edgewall Software

Ticket #2719 (closed defect: worksforme)

Opened 3 years ago

Last modified 23 months ago

trac is broken for sqlite-3.3.3

Reported by: trac@… Owned by: jonas
Priority: high Milestone:
Component: general Version: 0.9.4
Severity: critical Keywords: sqlite 3.3.3
Cc: trac@…

Description

My last sqlite version known as working is 3.2.7

For 3.3.3 (= new multi-threading support) is trac broken: 

Oops...

Trac detected an internal error:

You can only execute one statement at a time.

Traceback (most recent call last):
  File "/srv/tracs/trac.cgi", line 20, in ?
    cgi_frontend.run()
  File "/usr/lib/python2.4/site-packages/trac/web/cgi_frontend.py", line 124, in run
    env = get_environment(req, os.environ, threaded=False)
  File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 335, in get_environment
    return _open_environment(env_path, threaded)
  File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 44, in _open_environment
    return open_environment(env_path)
  File "/usr/lib/python2.4/site-packages/trac/env.py", line 375, in open_environment
    if env.needs_upgrade():
  File "/usr/lib/python2.4/site-packages/trac/env.py", line 281, in needs_upgrade
    if participant.environment_needs_upgrade(db):
  File "/usr/lib/python2.4/site-packages/trac/env.py", line 334, in environment_needs_upgrade
    dbver = self.env.get_version(db)
  File "/usr/lib/python2.4/site-packages/trac/env.py", line 204, in get_version
    cursor.execute("SELECT value FROM system WHERE name='database_version'")
  File "/usr/lib/python2.4/site-packages/trac/db.py", line 219, in execute
    args or [])
  File "/usr/lib/python2.4/site-packages/trac/db.py", line 211, in _rollback_on_error
    return function(self, *args, **kwargs)
Warning: You can only execute one statement at a time.

Attachments

Change History

Changed 3 years ago by cboos

I'd like to have some additional informations:

  • Which PySqlite binding are you using (2.1.3, 2.0.7 or 1.1.7?)
  • Did you configure SQLite 3.3.3 with --enable-threadsafe? (actually, what is the output of head sqlite-3.3.3/config.log?)

Thanks!

(I have yet to check 3.3.3 for myself)

Changed 3 years ago by eblot

Is it really worth setting severity as blocker if Trac works fine with other minor release of SQLite ?

Changed 3 years ago by cboos

  • severity changed from blocker to critical

Right, it's not really a blocker, but 3.3.3 is the last stable version for SQLite 3 (even the only one available from the main download page), so it's serious enough... if the problem is confirmed, that is.

Changed 3 years ago by trac@…

  • cc trac@… added

1. pysqlite-1.0.1: 

/usr/lib/python2.4/site-packages/_sqlite.so
/usr/lib/python2.4/site-packages/sqlite
/usr/lib/python2.4/site-packages/sqlite/__init__.py
/usr/lib/python2.4/site-packages/sqlite/main.py

and pysqlite-2.0.5 (both installed) 

/usr/lib/python2.4/site-packages/pysqlite2/__init__.py
/usr/lib/python2.4/site-packages/pysqlite2/_sqlite.so
/usr/lib/python2.4/site-packages/pysqlite2/dbapi2.py
/usr/lib/python2.4/site-packages/pysqlite2/test
/usr/lib/python2.4/site-packages/pysqlite2/test/__init__.py
/usr/lib/python2.4/site-packages/pysqlite2/test/dbapi.py
/usr/lib/python2.4/site-packages/pysqlite2/test/factory.py
/usr/lib/python2.4/site-packages/pysqlite2/test/transactions.py
/usr/lib/python2.4/site-packages/pysqlite2/test/types.py
/usr/lib/python2.4/site-packages/pysqlite2/test/userfunctions.py

2. yep: 

Compiling source in /var/tmp/portage/sqlite-3.3.3/work/sqlite-3.3.3 ...
 * econf: updating sqlite-3.3.3/config.guess with /usr/share/gnuconfig/config.guess
 * econf: updating sqlite-3.3.3/config.sub with /usr/share/gnuconfig/config.sub
./configure --prefix=/usr --host=i686-pc-linux-gnu 
--mandir=/usr/share/man 
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc 
--localstatedir=/var/lib --enable-incore-db --enable-tempdb-in-ram 
--enable-threadsafe --build=i686-pc-linux-gnu

checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for i686-pc-linux-gnu-gcc... i686-pc-linux-gnu-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether i686-pc-linux-gnu-gcc accepts -g... yes
checking for i686-pc-linux-gnu-gcc option to accept ANSI C... none needed
checking for a sed that does not truncate output... /bin/sed
checking for egrep... grep -E
checking for ld used by i686-pc-linux-gnu-gcc... /usr/i686-pc-linux-gnu/bin/ld
checking if the linker (/usr/i686-pc-linux-gnu/bin/ld) is GNU ld... yes
checking for /usr/i686-pc-linux-gnu/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/i686-pc-linux-gnu-nm -B
checking whether ln -s works... yes
checking how to recognise dependent libraries... pass_all
checking how to run the C preprocessor... i686-pc-linux-gnu-gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for i686-pc-linux-gnu-g++... i686-pc-linux-gnu-g++
checking whether we are using the GNU C++ compiler... yes
checking whether i686-pc-linux-gnu-g++ accepts -g... yes
checking how to run the C++ preprocessor... i686-pc-linux-gnu-g++ -E
checking for i686-pc-linux-gnu-g77... i686-pc-linux-gnu-g77
checking whether we are using the GNU Fortran 77 compiler... yes
checking whether i686-pc-linux-gnu-g77 accepts -g... yes
checking the maximum length of command line arguments... 32768
checking command to parse /usr/bin/i686-pc-linux-gnu-nm -B output from i686-pc-linux-gnu-gcc object... ok
checking for objdir... .libs
checking for i686-pc-linux-gnu-ar... i686-pc-linux-gnu-ar
checking for i686-pc-linux-gnu-ranlib... i686-pc-linux-gnu-ranlib
checking for i686-pc-linux-gnu-strip... i686-pc-linux-gnu-strip
checking if i686-pc-linux-gnu-gcc static flag  works... yes
checking if i686-pc-linux-gnu-gcc supports -fno-rtti -fno-exceptions... no
checking for i686-pc-linux-gnu-gcc option to produce PIC... -fPIC
checking if i686-pc-linux-gnu-gcc PIC flag -fPIC works... yes
checking if i686-pc-linux-gnu-gcc supports -c -o file.o... yes
checking whether the i686-pc-linux-gnu-gcc linker (/usr/i686-pc-linux-gnu/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by i686-pc-linux-gnu-g++... /usr/i686-pc-linux-gnu/bin/ld
checking if the linker (/usr/i686-pc-linux-gnu/bin/ld) is GNU ld... yes
checking whether the i686-pc-linux-gnu-g++ linker (/usr/i686-pc-linux-gnu/bin/ld) supports shared libraries... yes
checking for i686-pc-linux-gnu-g++ option to produce PIC... -fPIC
checking if i686-pc-linux-gnu-g++ PIC flag -fPIC works... yes
checking if i686-pc-linux-gnu-g++ supports -c -o file.o... yes
checking whether the i686-pc-linux-gnu-g++ linker (/usr/i686-pc-linux-gnu/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
appending configuration tag "F77" to libtool
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for i686-pc-linux-gnu-g77 option to produce PIC... -fPIC
checking if i686-pc-linux-gnu-g77 PIC flag -fPIC works... yes
checking if i686-pc-linux-gnu-g77 supports -c -o file.o... yes
checking whether the i686-pc-linux-gnu-g77 linker (/usr/i686-pc-linux-gnu/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking for a BSD-compatible install... /bin/install -c
checking for gawk... gawk
Version set to 3.3
Release set to 3.3.3
Version number set to 3003003
checking for i686-pc-linux-gnu-gcc... (cached) i686-pc-linux-gnu-gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether i686-pc-linux-gnu-gcc accepts -g... (cached) yes
checking for i686-pc-linux-gnu-gcc option to accept ANSI C... (cached) none needed
checking switches for the host compiler... -O2 -mtune=athlon -march=i686
checking target compiler... i686-pc-linux-gnu-gcc
checking switches on the target compiler... -O2 -mtune=athlon -march=i686
checking target linker... i686-pc-linux-gnu-gcc
checking switches on the target compiler... checking for i686-pc-linux-gnu-ranlib... (cached) i686-pc-linux-gnu-ranlib
-O2 -mtune=athlon -march=i686
checking if host and target compilers are the same... yes
checking whether to support threadsafe operation... yes
checking for pthread_create in -lpthread... yes
checking whether to allow connections to be shared across threads... no
checking whether to support shared library linked as release mode or not... no
checking whether to use an in-ram database for temporary tables... no
checking if executables have the .exe suffix... unknown
checking for Tcl configuration... found /usr/lib/tclConfig.sh
checking for existence of /usr/lib/tclConfig.sh... loading
checking for library containing tgetent... -lreadline
checking for readline in -lreadline... yes
checking for library containing fdatasync... none required
checking readline header files... not specified: still searching...
checking readline.h usability... no
checking readline.h presence... no
checking for readline.h... no
checking for /usr/include/readline.h... no
checking for /usr/include/readline/readline.h... yes
checking for usleep... yes
checking for fdatasync... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating sqlite3.pc
sed -e s/--VERS--/3.3.3/ ./src/sqlite.h.in | \
sed -e s/--VERSION-NUMBER--/3003003/ >sqlite3.h
i686-pc-linux-gnu-gcc -O2 -mtune=athlon -march=i686 -o lemon ./tool/lemon.c
i686-pc-linux-gnu-gcc -O2 -mtune=athlon -march=i686 -o mkkeywordhash  -DSQLITE_OMIT_CURSOR           ./tool/mkkeywordhash.c
./mkkeywordhash >keywordhash.h
cp ./tool/lempar.c .
cp ./src/parse.y .
./lemon  -DSQLITE_OMIT_CURSOR           parse.y
mv parse.h parse.h.temp
awk -f ./addopcodes.awk parse.h.temp >parse.h
cat parse.h ./src/vdbe.c | gawk -f ./mkopcodeh.awk >opcodes.h
./libtool --mode=compile i686-pc-linux-gnu-gcc -O2 -mtune=athlon -march=i686 -DOS_UNIX=1 -DHAVE_USLEEP=1 -DHAVE_FDATASYNC=1 -I. -I./src -DNDEBUG  -I/usr/include -DTHREADSAFE=1 -DSQLITE_OMIT_CURSOR -c ./src/alter.c

...

Changed 3 years ago by cboos

Ok, SQLite 3.3.3 was built as it should have been.

But you have to upgrade your PySqlite bindings, 1.0.1 doesn't even support SQLite3 and 2.0.5 is not compatible with 3.3.3.

Please upgrade to 2.0.7 (check the PySqlite page for details).

Changed 3 years ago by anonymous

Well, fist I have managed to make packages for my gentoo: setuptools 0.6_alpha9, PySqlite 2.1.3 and 2.0.7. Both versions works in the end, but very slow (apache-2.0.55, https + trac.cgi). Images, i.e. trac logo, disapears sometimes.

And there is now a second problem. The pysqlite-trac login is at the moment "misconfigurated", so I put it here.

PySqlite installs, how ever, in the (apha) egg-format, which needs 

import pkg_resources
pkg_resources.require("pysqlite")  # select latest installed version

in trac/db.py.

which in turn is in the trac also broken -- it will write pysqlite the dll in 

~/.python-eggs/pysqlite-2.1.3-py2.4-linux-i686.egg-tmp/pysqlite2/_sqlite.so

This is a no no for an webserwer. Sure, you can unzip and delete this oster egg, but this is a mess ... 

Traceback (most recent call last):
  File "/srv/tracs/trac.cgi", line 19, in ?
    from trac.web import cgi_frontend
  File "/usr/lib/python2.4/site-packages/trac/web/cgi_frontend.py", line 26, in ?
    from trac.web.main import dispatch_request, get_environment, \
  File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 22, in ?
    from trac.env import open_environment
  File "/usr/lib/python2.4/site-packages/trac/env.py", line 21, in ?
    from trac import db, db_default, util
  File "/usr/lib/python2.4/site-packages/trac/db.py", line 210, in ?
    import pysqlite2.dbapi2 as sqlite
  File "/usr/lib/python2.4/site-packages/pysqlite-2.1.3-py2.4-linux-i686.egg/pysqlite2/dbapi2.py", line 32, in ?
  File "/usr/lib/python2.4/site-packages/pysqlite-2.1.3-py2.4-linux-i686.egg/pysqlite2/_sqlite.py", line 7, in ?
  File "/usr/lib/python2.4/site-packages/pysqlite-2.1.3-py2.4-linux-i686.egg/pysqlite2/_sqlite.py", line 4, in __bootstrap__
  File "/usr/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py", line 676, in resource_filename
    return get_provider(package_or_requirement).get_resource_filename(
  File "/usr/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py", line 1064, in get_resource_filename
    self._extract_resource(manager, self._eager_to_zip(name))
  File "/usr/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py", line 1081, in _extract_resource
    real_path = manager.get_cache_path(self.egg_name, self._parts(zip_path))
  File "/usr/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py", line 713, in get_cache_path
    ensure_directory(target_path)
  File "/usr/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py", line 2137, in ensure_directory
    os.makedirs(dirname)
  File "/usr/lib/python2.4/os.py", line 156, in makedirs
    makedirs(head, mode)
  File "/usr/lib/python2.4/os.py", line 156, in makedirs
    makedirs(head, mode)
  File "/usr/lib/python2.4/os.py", line 156, in makedirs
    makedirs(head, mode)
  File "/usr/lib/python2.4/os.py", line 159, in makedirs
    mkdir(name, mode)
OSError: [Errno 13] Permission denied: '/home/httpd'

Changed 3 years ago by m.c.

Slowdowns partialy solved

  • There is a deadlock for gecko based browser somewhere in trac/chrome code. All static parts, as in TracCgi described, should be taken from htdocs_location. But now I realized this not true for header_logo/src and project/icon. They are taken thru cgi from chrome/common location. This causes by hitting the "reload button" deadlock on this url (i.e. chrome/common/trac_banner.png). There are 2 waiting child processes until KeepAliveTimeout expires. The workaround is just prepending /my-static-stuff/ for the icon and the logo, but I suppouse this code is broken.

This happens for all tested trac and sqlite versions, so IMHO I just run into an another version-independent bug :(

  • subversion-1.2.3 and neon-0.24.7 works as it should. With a subversion-1.3.0 and neon-0.25.3 the apache tells you (for Timeline, Browse Source, ...): 
[error] Exception
[error] exceptions.AssertionError
[error] <exceptions.AssertionError instance at 0xb7c9942c>
[error] in 
[error] <bound method Pool.__del__ of <trac.versioncontrol.svn_fs.Pool object at 0xb64174cc>>

But svn-dav works as it should and futher I don't see any visual impact on trac.

I hope my "investigations" helps somebody with same problems.

m.c.

Changed 3 years ago by m.c.

  • status changed from new to closed
  • resolution set to fixed

1. pysqlite-2.0.7 and sqlite-3.3.4 problem solved for gentoo see http://bugs.gentoo.org/show_bug.cgi?id=121460#c7

Future pysqlite versions defaults no more to egg packaging see http://initd.org/tracker/pysqlite/ticket/145

2. it was not deadlock but wrong date format in the http response header. Works now in 0.9.4, see #2006 .

3. subversion-1.3.0 & neon-0.25.5 still produce apache error: 

[error] Exception
exceptions.AssertionError
<exceptions.AssertionError instance at 0xb7d1d42c>
in
<bound method Pool.__del__ of <trac.versioncontrol.svn_fs.Pool object at 0xb648baac>>
ignored

but this is not sqlite related, so I close the ticket.

Changed 2 years ago by devein ( acmosis@…

  • status changed from closed to reopened
  • version changed from 0.9.3 to 0.9.4
  • resolution fixed deleted

the same here at debian testing distribution

todays upgrade of libsqlite package resulted in identical error as this bug description

latest working debian package: libsqlite3-0_3.2.8-1_i386.deb

package causing Trac error: libsqlite3-0_3.3.5-0.1_i386.deb

link to debian repository: http://packages.debian.org/testing/libs/libsqlite3-0

after downgrading, trac works: 

dpkg -i libsqlite3-0_3.2.8-1_i386.deb
dpkg - warning: downgrading libsqlite3-0 from 3.3.5-0.1 to 3.2.8-1.
(Reading database ... 48002 files and directories currently installed.)
Preparing to replace libsqlite3-0 3.3.5-0.1 (using libsqlite3-0_3.2.8-1_i386.deb) ...
Unpacking replacement libsqlite3-0 ...
Setting up libsqlite3-0 (3.2.8-1) ...

Changed 2 years ago by cboos

You didn't mention what your PySqlite version was. Most probably it's not one compatible with SQLite >= 3.3.3.

Please take the time to fully read the information provided in this ticket and also in the PySqlite page, the section about the versions.

(and then please close the ticket as worksforme)

Changed 2 years ago by anonymous

  • status changed from reopened to closed
  • resolution set to worksforme

dpkg -s python2.3-pysqlite2

Pysqlite: Version: 2.0.5-1 debian package link&version info: http://packages.debian.org/testing/python/python2.3-pysqlite2

from pysqlite trac page : 

...
or, better, the newer 2.0.x release branch

    * version >= 2.0.5 preferred, 
    * version 2.0.7 required if using SQLite >= 3.3.3
...

so, i guess that trac is not responsible for these changes , should i notify debian package maintainer (python-sqlite one?) that python-sqlite+libsqlite+sqlite debian packages should more strictly specify their respective versions?

Changed 2 years ago by cboos

Well, you should basically tell the python-pysqlite package maintainer to subscribe to the PySqlite mailing list :)

But yes, the upgrade to either 1.1.7, 2.0.7, 2.1.3 or 2.2.x is really mandatory when using a recent sqlite3 library (>= 3.3.3).

Add/Change #2719 (trac is broken for sqlite-3.3.3)

Author



Change Properties
<Author field>
Action
as closed
Next status will be 'reopened'
 
Note: See TracTickets for help on using tickets.