Ticket #1528 (closed defect: wontfix)
segfault during initenv
| Reported by: | exarkun@… | Owned by: | cboos |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | version control | Version: | 0.10.3.1 |
| Severity: | critical | Keywords: | svn130 svn131 |
| Cc: | EricJohnson, <edgewall@…> |
Description (last modified by cboos) (diff)
twisted@muon:~$ trac-admin run/trac/projectenv initenv Twisted run/trac/Twisted-repository/ /home/twisted/share/trac/templates Creating and Initializing Project Inserting default data Configuring Project trac.repository_dir trac.templates_dir project.name Installing default wiki macros /home/twisted/share/trac/wiki-macros/HelloWorld.py => HelloWorld.py /home/twisted/share/trac/wiki-macros/TracGuideToc.py => TracGuideToc.py /home/twisted/share/trac/wiki-macros/Timestamp.py => Timestamp.py Installing default wiki pages /home/twisted/share/trac/wiki-default/TracTicketsCustomFields => TracTicketsCustomFields /home/twisted/share/trac/wiki-default/TracMultipleProjects => TracMultipleProjects /home/twisted/share/trac/wiki-default/TracBackup => TracBackup /home/twisted/share/trac/wiki-default/TracTimeline => TracTimeline /home/twisted/share/trac/wiki-default/TracTickets => TracTickets /home/twisted/share/trac/wiki-default/TracInstall => TracInstall /home/twisted/share/trac/wiki-default/TracRss => TracRss /home/twisted/share/trac/wiki-default/TracImport => TracImport /home/twisted/share/trac/wiki-default/WikiPageNames => WikiPageNames /home/twisted/share/trac/wiki-default/WikiRestructuredText => WikiRestructuredText /home/twisted/share/trac/wiki-default/TracPermissions => TracPermissions /home/twisted/share/trac/wiki-default/TracSupport => TracSupport /home/twisted/share/trac/wiki-default/WikiHtml => WikiHtml /home/twisted/share/trac/wiki-default/TracIni => TracIni /home/twisted/share/trac/wiki-default/TracModPython => TracModPython /home/twisted/share/trac/wiki-default/TracSyntaxColoring => TracSyntaxColoring /home/twisted/share/trac/wiki-default/TracBrowser => TracBrowser /home/twisted/share/trac/wiki-default/WikiFormatting => WikiFormatting /home/twisted/share/trac/wiki-default/TracNotification => TracNotification /home/twisted/share/trac/wiki-default/TracUnicode => TracUnicode /home/twisted/share/trac/wiki-default/TracAccessibility => TracAccessibility /home/twisted/share/trac/wiki-default/TracEnvironment => TracEnvironment /home/twisted/share/trac/wiki-default/TracReports => TracReports /home/twisted/share/trac/wiki-default/WikiMacros => WikiMacros /home/twisted/share/trac/wiki-default/TracInstallPlatforms => TracInstallPlatforms /home/twisted/share/trac/wiki-default/CamelCase => CamelCase /home/twisted/share/trac/wiki-default/WikiProcessors => WikiProcessors /home/twisted/share/trac/wiki-default/TracSearch => TracSearch /home/twisted/share/trac/wiki-default/TracQuery => TracQuery /home/twisted/share/trac/wiki-default/WikiStart => WikiStart /home/twisted/share/trac/wiki-default/TracLogging => TracLogging /home/twisted/share/trac/wiki-default/SandBox => SandBox /home/twisted/share/trac/wiki-default/WikiRestructuredTextLinks => WikiRestructuredTextLinks /home/twisted/share/trac/wiki-default/TracLinks => TracLinks /home/twisted/share/trac/wiki-default/TracRoadmap => TracRoadmap /home/twisted/share/trac/wiki-default/TracStandalone => TracStandalone /home/twisted/share/trac/wiki-default/TracUpgrade => TracUpgrade /home/twisted/share/trac/wiki-default/RecentChanges => RecentChanges /home/twisted/share/trac/wiki-default/TracAdmin => TracAdmin /home/twisted/share/trac/wiki-default/TracGuide => TracGuide /home/twisted/share/trac/wiki-default/TracChangeset => TracChangeset /home/twisted/share/trac/wiki-default/TitleIndex => TitleIndex /home/twisted/share/trac/wiki-default/WikiNewPage => WikiNewPage /home/twisted/share/trac/wiki-default/TracWiki => TracWiki Indexing repository Segmentation fault twisted@muon:~$
Using revision 1646 of trac, debian unstable packaged Python 2.4.1, swig, sqlite, python2.4-subversion.
Can produce a core file if necessary or helpful.
Output from running trac-admin with strace ends with these lines:
stat64("/usr/lib/python2.4/site-packages/swig_runtime_data1", 0xbfffe270) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.4/site-packages/swig_runtime_data1.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.4/site-packages/swig_runtime_data1module.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.4/site-packages/swig_runtime_data1.py", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.4/site-packages/swig_runtime_data1.pyc", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
futex(0x814a7e8, FUTEX_WAKE, 1) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV (core dumped) +++
twisted@muon:~$
Attachments
Change History
comment:2 Changed 4 years ago by cboos
- Status changed from new to closed
- Resolution set to worksforme
- Description modified (diff)
The svn bindings have seen much progress in the last months, I believe this ticket can now safely be closed.
comment:3 Changed 4 years ago by cfis@…
- Status changed from closed to reopened
- Resolution worksforme deleted
- Version changed from devel to 0.9.4
- Component changed from trac-admin to version control
- Severity changed from major to critical
I still run into this problem. Setup is trac 0.9.4, Fedora Core 4, SVN 1.3.0 or 1.3.1 Happens when trying to create a new trac project against any SVN project (including a new one).
Here is the trace from running under GDB:
/usr/share/trac/wiki-default/TracSyntaxColoring => TracSyntaxColoring Indexing repository
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208330560 (LWP 1296)] 0x003d55ef in apr_pool_create_ex (newpool=0x13e570, parent=0x0, abort_fn=0, allocator=0x0) at apr_pools.c:802 802 allocator = parent->allocator; (gdb) bt #0 0x003d55ef in apr_pool_create_ex (newpool=0x13e570, parent=0x0, abort_fn=0, allocator=0x0)
at apr_pools.c:802
#1 0x00138ef6 in svn_swig_py_release_py_lock ()
at /usr/src/subversion-1.3.1/subversion/bindings/swig/python/libsvn_swig_py/swigutil_py.c:77
#2 0x005b9886 in init_core () from /usr/lib/python2.4/site-packages/libsvn/_core.so #3 0x00ad91f3 in PyCFunction_Call () from /usr/lib/libpython2.4.so.1.0 #4 0x00b12092 in PyEval?_EvalFrame () from /usr/lib/libpython2.4.so.1.0 #5 0x00b12ef8 in PyEval?_EvalCodeEx () from /usr/lib/libpython2.4.so.1.0 #6 0x00b1169c in PyEval?_EvalFrame () from /usr/lib/libpython2.4.so.1.0 #7 0x00b12ef8 in PyEval?_EvalCodeEx () from /usr/lib/libpython2.4.so.1.0 #8 0x00ac7be1 in PyFunction?_SetClosure () from /usr/lib/libpython2.4.so.1.0 #9 0x00ab33b4 in PyObject?_Call () from /usr/lib/libpython2.4.so.1.0 #10 0x00abac76 in PyMethod?_Fini () from /usr/lib/libpython2.4.so.1.0 #11 0x00ab33b4 in PyObject?_Call () from /usr/lib/libpython2.4.so.1.0 #12 0x00af0c92 in _PyObject_SlotCompare () from /usr/lib/libpython2.4.so.1.0 #13 0x00ae9fb6 in PyType?_IsSubtype () from /usr/lib/libpython2.4.so.1.0 #14 0x00ab33b4 in PyObject?_Call () from /usr/lib/libpython2.4.so.1.0 #15 0x00b10bde in PyEval?_EvalFrame () from /usr/lib/libpython2.4.so.1.0 #16 0x00b12ef8 in PyEval?_EvalCodeEx () from /usr/lib/libpython2.4.so.1.0 #17 0x00b13228 in PyEval?_EvalCode () from /usr/lib/libpython2.4.so.1.0 #18 0x00b26acf in PyImport?_ExecCodeModuleEx () from /usr/lib/libpython2.4.so.1.0 #19 0x00b27ca3 in _PyImport_Init () from /usr/lib/libpython2.4.so.1.0 #20 0x00b29752 in PyImport?_ReloadModule () from /usr/lib/libpython2.4.so.1.0 #21 0x00b29976 in PyImport?_ReloadModule () from /usr/lib/libpython2.4.so.1.0 #22 0x00b29e5a in PyImport?_ImportModuleEx () from /usr/lib/libpython2.4.so.1.0 #23 0x00b04b9e in _PyUnicodeUCS4_IsAlpha () from /usr/lib/libpython2.4.so.1.0 #24 0x00ad91f3 in PyCFunction_Call () from /usr/lib/libpython2.4.so.1.0 #25 0x00ab33b4 in PyObject?_Call () from /usr/lib/libpython2.4.so.1.0 #26 0x00b0c1c0 in PyEval?_CallObjectWithKeywords () from /usr/lib/libpython2.4.so.1.0 #27 0x00b0f3b0 in PyEval?_EvalFrame () from /usr/lib/libpython2.4.so.1.0 #28 0x00b12ef8 in PyEval?_EvalCodeEx () from /usr/lib/libpython2.4.so.1.0 #29 0x00b1169c in PyEval?_EvalFrame () from /usr/lib/libpython2.4.so.1.0 #30 0x00b117e4 in PyEval?_EvalFrame () from /usr/lib/libpython2.4.so.1.0 #31 0x00b12ef8 in PyEval?_EvalCodeEx () from /usr/lib/libpython2.4.so.1.0 #32 0x00ac7be1 in PyFunction?_SetClosure () from /usr/lib/libpython2.4.so.1.0 #33 0x00ab33b4 in PyObject?_Call () from /usr/lib/libpython2.4.so.1.0 #34 0x00abac76 in PyMethod?_Fini () from /usr/lib/libpython2.4.so.1.0 #35 0x00ab33b4 in PyObject?_Call () from /usr/lib/libpython2.4.so.1.0 #36 0x00b10bde in PyEval?_EvalFrame () from /usr/lib/libpython2.4.so.1.0 #37 0x00b117e4 in PyEval?_EvalFrame () from /usr/lib/libpython2.4.so.1.0 #38 0x00b117e4 in PyEval?_EvalFrame () from /usr/lib/libpython2.4.so.1.0 #39 0x00b12ef8 in PyEval?_EvalCodeEx () from /usr/lib/libpython2.4.so.1.0 #40 0x00b13228 in PyEval?_EvalCode () from /usr/lib/libpython2.4.so.1.0 #41 0x00b2f55a in PyErr?_Display () from /usr/lib/libpython2.4.so.1.0 #42 0x00b307d2 in PyRun?_SimpleFileExFlags () from /usr/lib/libpython2.4.so.1.0 #43 0x00b31269 in PyRun?_AnyFileExFlags () from /usr/lib/libpython2.4.so.1.0 #44 0x00b3716d in Py_Main () from /usr/lib/libpython2.4.so.1.0 #45 0x080485ba in main ()
comment:4 Changed 4 years ago by cboos
- Owner changed from daniel to cboos
- Status changed from reopened to new
Well, first thing would be to recompile the bindings with the -g flag added to COMPILE_PY_WRAPPER in the toplevel Makefile, as the line number information in init_core (), frame #2 is really critical.
It looks like svn_swig_py_release_py_lock is called before svn_swig_py_initialize, which really shouldn't happen...
comment:5 Changed 4 years ago by EricJohnson <edgewall@…>
- Cc EricJohnson, <edgewall@…> added
I was getting segfaults. I'm not sure its the same as whats going on here in this bug. I am not a manly enough developer that I know how to hook up trac-admin to gdb. However, I did manage to solve my problem. I had upgraded to a new version of trac when I started getting segfaults. Solution: mv /usr/lib/python2.4/site-packages/trac to /usr/lib/python2.4/site-packages/trac.old, then rerun the trac installer (python ./setup.py install). Surely there is/should be a better more automagic way of doing upgrades?
comment:6 Changed 4 years ago by EricJohnson <edgewall@…>
nevermind, ignore what i said earlier. i get a segfault for trac from svn .10dev (version 3390), but not from trac 0.9.5 stable. i am using subversion 1.2.3, postgres, and gentoo
comment:7 Changed 4 years ago by cboos
Eric, I assume that you had you're segfault doing an initenv, right? Running trac-admin under gdb isn't a big deal, do something like:
gdb /usr/bin/python /usr/lib/python2.4/scripts/trac-admin initenv
or resync instead of initenv if the TracEnvironment already exist and is usable.
comment:8 follow-up: ↓ 9 Changed 4 years ago by bjdyck@…
I don't have handy access to my server from work so I can't provide any gdb traces, but I ran into this problem last night where initenv resulted in a segfault; in my case, it occurred earlier than the one reported in the initial bug report - running trac-admin in interactive mode, it would occur immediately after specifiying the Trac template directory.
Unless otherwise noted, everything in the following list comes from prebuilt packages for Ubuntu Dapper (either universe or multiverse):
- Subversion 1.3.1 with SWIG bindings
- Clearsilver 0.9.x (memory's hazy here)
- PostgreSQL 8.1
- psycopg 1.1.x (would love to use v2.x, but am trying to stick to existing packages)
- Python 2.4
Like Eric reports, the segfault would occur when attempting to do an initenv with a recent trunk build (0.10dev); it works flawlessly with 0.9.5stable.
comment:9 in reply to: ↑ 8 ; follow-up: ↓ 10 Changed 4 years ago by anonymous
Replying to bjdyck@gmail.com:
Is the same version of the Subversion bindings used in both situations?Like Eric reports, the segfault would occur when attempting to do an initenv with a recent trunk build (0.10dev); it works flawlessly with 0.9.5stable.
Besides, without any information about where the crash occurred (it could be anywhere, e.g. in an incompatible apr library), there's no way I can help...
comment:10 in reply to: ↑ 9 ; follow-up: ↓ 11 Changed 4 years ago by bjdyck@…
Replying to anonymous:
Is the same version of the Subversion bindings used in both situations?
Besides, without any information about where the crash occurred (it could be anywhere, e.g. in an incompatible apr library), there's no way I can help...
I didn't change anything related to Subversion for either 0.9.5stable or 0.10dev, so the SVN bindings shouldn't be affected...
Unfortunately, I'll need to install the gcc toolchain on my server before I can provide any more information, as it's not currently installed.
comment:11 in reply to: ↑ 10 Changed 4 years ago by cboos
- Keywords svn130 svn131 added
Replying to bjdyck@gmail.com:
Please do, that would really help; installing gdb should be enough. See comment:7...., I'll need to install the gcc toolchain on my server before I can provide any more information, as it's not currently installed.
comment:12 Changed 3 years ago by cboos
- Status changed from new to closed
- Resolution set to worksforme
No additional info on this one since a few months...
If someone wants to reopen this ticket because he sees the same issue again, be sure to:
- use recent bindings (1.4.x preferred)
- follow the instructions given above for generating a correct backtrace (without it, we can do much)
comment:13 Changed 3 years ago by Olivier
- Status changed from closed to reopened
- Version changed from 0.9.4 to 0.10.3.1
- Resolution worksforme deleted
Hello,
my problem is not exaltly the same but I believe the error is coming from the same root.
For some reason I have to upgrade my svn version to 1.4.1, so I rebuild the python binding and here we are now my trac.cgi do a segfault
here is the backtrace
#0 apr_pool_create_ex (newpool=0x40773e40, parent=0x0, abort_fn=0, allocator=0x0) at apr_pools.c:802
#1 0x4076e680 in svn_swig_py_release_py_lock ()
at /tmp/subversion-1.4.3/subversion/bindings/swig/python/libsvn_swig_py/swigutil_py.c:78
#2 0x409b7507 in init_core () from /usr/lib/python2.3/site-packages/libsvn/_core.so
#3 0x080fdd2a in PyCFunction_Call ()
#4 0x080ab6f4 in PyEval_CallObjectWithKeywords ()
#5 0x080a9aae in Py_MakePendingCalls ()
#6 0x080aa63c in PyEval_EvalCodeEx ()
#7 0x080fd877 in PyStaticMethod_New ()
#8 0x0805b989 in PyObject_Call ()
#9 0x080623d8 in PyMethod_Fini ()
#10 0x0805b989 in PyObject_Call ()
#11 0x0808edef in _PyObject_SlotCompare ()
#12 0x080899b5 in _PyObject_SlotCompare ()
#13 0x0805b989 in PyObject_Call ()
#14 0x080ab912 in PyEval_CallObjectWithKeywords ()
#15 0x080ab579 in PyEval_CallObjectWithKeywords ()
#16 0x080a9aae in Py_MakePendingCalls ()
#17 0x080aa63c in PyEval_EvalCodeEx ()
#18 0x080ace39 in PyEval_EvalCode ()
#19 0x080cbfe6 in PyImport_ExecCodeModuleEx ()
#20 0x080cee23 in PyImport_ExtendInittab ()
#21 0x080ccb2e in PyImport_ExecCodeModuleEx ()
#22 0x080cda28 in PyImport_ImportModule ()
#23 0x080cd553 in PyImport_ImportModule ()
#24 0x080cf6df in PyImport_ExtendInittab ()
#25 0x080ce65c in PyImport_ImportModuleEx ()
#26 0x080a0bc1 in _PyBuiltin_Init ()
#27 0x080fdd2a in PyCFunction_Call ()
#28 0x080ab6f4 in PyEval_CallObjectWithKeywords ()
#29 0x080a9aae in Py_MakePendingCalls ()
#30 0x080aa63c in PyEval_EvalCodeEx ()
#31 0x080ab7a9 in PyEval_CallObjectWithKeywords ()
#32 0x080ab5ec in PyEval_CallObjectWithKeywords ()
#33 0x080a9aae in Py_MakePendingCalls ()
#34 0x080aa63c in PyEval_EvalCodeEx ()
#35 0x080fd877 in PyStaticMethod_New ()
#36 0x0805b989 in PyObject_Call ()
#37 0x080623d8 in PyMethod_Fini ()
most apparently parent is egal to null and it shouldn't be.....
any suggestion would be greatly apprecied
comment:14 Changed 3 years ago by olivier
- Status changed from reopened to closed
- Resolution set to wontfix
Sorry was a problem with the binding
my apologize to have reopen this ticket for nothing




Are you able to run trac-admin under gdb and get a backtrace when it segfaults? By the looks of the strace output you provided it's a SWIG-related problem. It's hard to tell where it's dying without a C-level backtrace though.