Edgewall Software
Modify

Ticket #1528 (closed defect: wontfix)

Opened 5 years ago

Last modified 3 years ago

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

trac-admin Download (2.3 KB) - added by exarkun@… 5 years ago.
gdb backtrace

Change History

comment:1 Changed 5 years ago by mrowe

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.

Changed 5 years ago by exarkun@…

gdb backtrace

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:

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...

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:

..., 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 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

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
Next status will be 'reopened'
to The owner will be changed from cboos. Next status will be 'closed'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.