Hi there,
There seems to be a problem with the swig wrappers of subversion which
shows up in 1.3.24. Here is the information I gathered:
On Thu, Mar 17, 2005 at 12:29:59PM -0000, Max Bowsher wrote:
> Torsten Landschoff wrote:
> > [...]
> >- Trac (a lightweight version resembling something like source forge)
> > uses the python bindings of subversion for repository access
> >- Upgrading subversion to the latest version breaks trac
> >- The only change from subversion 1.1.3-1 to 1.1.3-2 (Debian revisions)
> > was to move from swig 1.3.22 to swig 1.3.24
> >
> >For more information please have a look at the report logs at
> >
> >http://bugs.debian.org/299817 and http://bugs.debian.org/298888
> > [...]
> >(gdb) bt
> >#0 0xb7e827ab in raise () from /lib/tls/libc.so.6
> >#1 0xb7e83f12 in abort () from /lib/tls/libc.so.6
> >#2 0x080d94a9 in Py_FatalError ()
> >#3 0x080d76ef in PyThreadState_Get ()
> >#4 0x080ad18b in PyEval_GetGlobals ()
> >#5 0x080cdffb in PyImport_Import ()
> >#6 0x080cd407 in PyImport_ImportModule ()
> >#7 0x080f69dc in PyCObject_Import ()
> >#8 0xb794ca81 in SWIG_Python_GetTypeListHandle () at pyrun.swg:731
> >#9 0xb794edf0 in SWIG_Python_GetTypeList () at pyrun.swg:747
> >#10 0xb794edce in SWIG_Runtime_TypeQuery (name=0xb794f36b
> >"svn_log_changed_path_t *") at runtime.swg:20 #11 0xb794eba7 in
> >svn_swig_py_log_receiver (baton=0xb7dd9c84,
> >changed_paths=0x829a4a8, rev=1, author=0x829e728 "www-data",
> >date=0x82b8ba0 "2005-03-17T08:59:07.102288Z", msg=0x82cd200 "Test",
> >pool=0x829a410) at
> >/home/torsten/tracking-swig-bug/subversion-1.1.3/build-tree/subversion-1.1.3/subversion/bindings/swig/python/libsvn_swig_py/swigutil_py.c:1276
> > [...]
> >The line in question in swigutil_py.c (1276) is
> >
> > swig_type_info *tinfo = SWIG_TypeQuery("svn_log_changed_path_t *");
> >
> >At that point python aborts with the message
> >
> > Fatal Python error: PyThreadState_Get: no current thread
> Ah... I think I see the problem...
>
> Subversion releases the Python global interpreter lock when it drops into C
> code, to avoid other Python threads from blocking unnecessarily... but then
> goes and calls SWIG_TypeQuery...
>
> When the runtime type data was being shared via C linkage, this wasn't a
> problem.
>
> But now that SWIG_TypeQuery makes calls to Python, this is very bad.
>
> Um.
>
> Any suggestions?
>
> I suppose we just have to find an acceptably elegant way of running
> SWIG_TypeQuery earlier, and stashing the return value somewhere it can be
> got at when required.
From this information I created the following quick hack to fix or at
least work around the problem. It would surely be more elegant to get
the type once. OTOH the interaction with the svn server will most
probably be much slower than the swig type lookups.
Index: subversion-1.1.3/subversion/bindings/swig/python/libsvn_swig_py/swigutil_py.c
===================================================================
--- subversion-1.1.3.orig/subversion/bindings/swig/python/libsvn_swig_py/swigutil_py.c 2005-03-18 01:17:55.747298032 +0100
+++ subversion-1.1.3/subversion/bindings/swig/python/libsvn_swig_py/swigutil_py.c 2005-03-18 01:24:17.883204544 +0100
@@ -1273,7 +1273,7 @@
{
PyObject *receiver = baton;
PyObject *result;
- swig_type_info *tinfo = SWIG_TypeQuery("svn_log_changed_path_t *");
+ swig_type_info *tinfo;
PyObject *chpaths;
svn_error_t *err = SVN_NO_ERROR;
@@ -1281,6 +1281,7 @@
return SVN_NO_ERROR;
svn_swig_py_acquire_py_lock();
+ tinfo = SWIG_TypeQuery("svn_log_changed_path_t *");
if (changed_paths)
{
Thanks for reading
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 18 01:24:18 2005