Hi David, On Wed, Mar 16, 2005 at 09:31:38PM -0800, David Kimdon wrote: > There are two bugs filed against subversion that look related to the recent > swig upgrade. I am unable to pursue these at this time but they look > rather important. I am hoping someone could take up the torch and > look into them: > > #298888 libsvn0: breaks log feature in python libsvn > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298888 > > #299817 python2.3-subversion: trac revision log breaks > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=299817
I reproduced this bug and got python running track into gdb. Here is the
backtrace:
#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 0xb798fa81 in ?? () from /usr/lib/libsvn_swig_py-1.so.0
#9 0xb7992057 in ?? () from /usr/lib/libsvn_swig_py-1.so.0
#10 0xb799204a in ?? () from /usr/lib/libsvn_swig_py-1.so.0
#11 0xbfffecb8 in ?? ()
#12 0xb780dbb3 in apr_pool_destroy () from /usr/lib/libapr-0.so.0
#13 0xb7991df0 in svn_swig_py_log_receiver () from
/usr/lib/libsvn_swig_py-1.so.0
#14 0xb7991dce in svn_swig_py_log_receiver () from
/usr/lib/libsvn_swig_py-1.so.0
#15 0xb7991ba7 in svn_swig_py_log_receiver () from
/usr/lib/libsvn_swig_py-1.so.0
#16 0xb759b544 in svn_repos_get_logs2 () from
/usr/lib/libsvn_repos-1.so.0
#17 0xb759b5fd in svn_repos_get_logs () from
/usr/lib/libsvn_repos-1.so.0
#18 0xb75e10e3 in init_repos () from
/usr/lib/python2.3/site-packages/libsvn/_repos.so
#19 0x080fde6a in PyCFunction_Call ()
#20 0x080ab834 in PyEval_CallObjectWithKeywords ()
#21 0x080a9bee in Py_MakePendingCalls ()
#22 0x080ab96d in PyEval_CallObjectWithKeywords ()
#23 0x080ab72c in PyEval_CallObjectWithKeywords ()
#24 0x080a9bee in Py_MakePendingCalls ()
#25 0x080ab96d in PyEval_CallObjectWithKeywords ()
#26 0x080ab72c in PyEval_CallObjectWithKeywords ()
#27 0x080a9bee in Py_MakePendingCalls ()
#28 0x080ab96d in PyEval_CallObjectWithKeywords ()
#29 0x080ab72c in PyEval_CallObjectWithKeywords ()
#30 0x080a9bee in Py_MakePendingCalls ()
#31 0x080aa77c in PyEval_EvalCodeEx ()
#32 0x080ab8e9 in PyEval_CallObjectWithKeywords ()
#33 0x080ab72c in PyEval_CallObjectWithKeywords ()
#34 0x080a9bee in Py_MakePendingCalls ()
#35 0x080ab96d in PyEval_CallObjectWithKeywords ()
#36 0x080ab72c in PyEval_CallObjectWithKeywords ()
#37 0x080a9bee in Py_MakePendingCalls ()
#38 0x080ab96d in PyEval_CallObjectWithKeywords ()
#39 0x080ab72c in PyEval_CallObjectWithKeywords ()
#40 0x080a9bee in Py_MakePendingCalls ()
#41 0x080aa77c in PyEval_EvalCodeEx ()
#42 0x080acf79 in PyEval_EvalCode ()
#43 0x080d90db in PyRun_FileExFlags ()
#44 0x080d885f in PyRun_SimpleFileExFlags ()
#45 0x08054e95 in Py_Main ()
#46 0x080549eb in main ()
This looks to me like a problem with whatever is linked to
apr_pool_destroy. Probably there is a callback to clean up the python
relevant stuff which fails for some reason. No time to look into this
further now.
Greetings
Torsten
signature.asc
Description: Digital signature
