Hi again, On Thu, Mar 17, 2005 at 10:15:13AM +0100, Torsten Landschoff wrote: > 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.
... but I could not resist. After rebuilding subversion without
stripping the objects I get the following dump:
#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
#12 0xb7454544 in svn_repos_get_logs2 (repos=0x8275e10, paths=0x82771b0,
start=0, end=1, discover_changed_paths=1, strict_node_history=0,
authz_read_func=0, authz_read_baton=0x0, receiver=0xb794eb81
<svn_swig_py_log_receiver>, receiver_baton=0xb7dd9c84, pool=0x8275bf0)
at subversion/libsvn_repos/log.c:411
#13 0xb74545fd in svn_repos_get_logs (repos=0x8275e10, paths=0x82771b0,
start=0, end=1, discover_changed_paths=1, strict_node_history=0,
receiver=0xb794eb81 <svn_swig_py_log_receiver>, receiver_baton=0xb7dd9c84,
pool=0x8275bf0) at subversion/libsvn_repos/log.c:440
#14 0xb749a0e3 in _wrap_svn_repos_get_logs (self=0x0, args=0x1) at
subversion/bindings/swig/python/svn_repos.c:3907
#15 0x080fde6a in PyCFunction_Call ()
#16 0x080ab834 in PyEval_CallObjectWithKeywords ()
#17 0x080a9bee in Py_MakePendingCalls ()
#18 0x080ab96d in PyEval_CallObjectWithKeywords ()
#19 0x080ab72c in PyEval_CallObjectWithKeywords ()
#20 0x080a9bee in Py_MakePendingCalls ()
#21 0x080ab96d in PyEval_CallObjectWithKeywords ()
#22 0x080ab72c in PyEval_CallObjectWithKeywords ()
#23 0x080a9bee in Py_MakePendingCalls ()
#24 0x080ab96d in PyEval_CallObjectWithKeywords ()
#25 0x080ab72c in PyEval_CallObjectWithKeywords ()
#26 0x080a9bee in Py_MakePendingCalls ()
#27 0x080aa77c in PyEval_EvalCodeEx ()
#28 0x080ab8e9 in PyEval_CallObjectWithKeywords ()
#29 0x080ab72c in PyEval_CallObjectWithKeywords ()
#30 0x080a9bee in Py_MakePendingCalls ()
#31 0x080ab96d in PyEval_CallObjectWithKeywords ()
#32 0x080ab72c in PyEval_CallObjectWithKeywords ()
#33 0x080a9bee in Py_MakePendingCalls ()
#34 0x080ab96d in PyEval_CallObjectWithKeywords ()
#35 0x080ab72c in PyEval_CallObjectWithKeywords ()
#36 0x080a9bee in Py_MakePendingCalls ()
#37 0x080aa77c in PyEval_EvalCodeEx ()
#38 0x080acf79 in PyEval_EvalCode ()
#39 0x080d90db in PyRun_FileExFlags ()
#40 0x080d885f in PyRun_SimpleFileExFlags ()
#41 0x08054e95 in Py_Main ()
#42 0x080549eb in main ()
Now it seems like something goes wrong in SWIG_Runtime_TypeQuery which
is part of the new code for 1.3.24 replacing the old runtime. Looks like
this really is a swig problem. Taking over the bugs...
Greetings
Torsten
signature.asc
Description: Digital signature
