Opened 20 years ago
Closed 18 years ago
#1528 closed defect (wontfix)
segfault during initenv
Reported by: | Owned by: | Christian Boos | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | version control | Version: | 0.10.3.1 |
Severity: | critical | Keywords: | svn130 svn131 |
Cc: | EricJohnson, <edgewall@…> | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description (last modified by )
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 (1)
Change History (15)
comment:1 by , 20 years ago
comment:2 by , 19 years ago
Description: | modified (diff) |
---|---|
Resolution: | → worksforme |
Status: | new → closed |
The svn bindings have seen much progress in the last months, I believe this ticket can now safely be closed.
comment:3 by , 19 years ago
Component: | trac-admin → version control |
---|---|
Resolution: | worksforme |
Severity: | major → critical |
Status: | closed → reopened |
Version: | devel → 0.9.4 |
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 by , 19 years ago
Owner: | changed from | to
---|---|
Status: | reopened → 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 by , 19 years ago
Cc: | 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 by , 19 years ago
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 by , 19 years ago
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.
follow-up: 9 comment:8 by , 19 years ago
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.
follow-up: 10 comment:9 by , 19 years ago
Replying to bjdyck@gmail.com:
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.
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…
follow-up: 11 comment:10 by , 19 years ago
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 by , 19 years ago
Keywords: | svn130 svn131 added |
---|
Replying to bjdyck@gmail.com:
…, I'll need to install the gcc toolchain on my server before I can provide any more information, as it's not currently installed.
Please do, that would really help; installing gdb
should be enough. See comment:7.
comment:12 by , 18 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
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 by , 18 years ago
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
Version: | 0.9.4 → 0.10.3.1 |
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 by , 18 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
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.