On 10/5/05, David James <james82@gmail.com> wrote:
> On 10/5/05, Max Bowsher <maxb@ukf.net> wrote:
> > David James wrote:
> > > On 10/4/05, Max Bowsher <maxb@ukf.net> wrote:
> > >> David James wrote:
> > >>> On 10/4/05, Max Bowsher <maxb@ukf.net> wrote:
> > >>>> David James wrote:
> > >>>>>
> > >>>>> import _wc
> > >>>>>
> > >>>>> Oops! We imported _wc before importing _core. I'm not sure why
> > >>>>> importing _wc before _core leads to crashes on my machine now -- it
> > >>>>> used to work fine.
> > >>>>
> > >>>> Could you try using gdb to figure out where it crashes?
> > >>>>
> > >>>> It does not crash for me, nor would I expect it to, as no use of APR is
> > >>>> made in the _wc initialization function.
> > >>>>
> > >>>> In an "import svn.wc" situation, APR will be initialized when the
> > >>>> "import
> > >>>> core" statement in libsvn.wc executes, which follows immediately
> > >>>> (except
> > >>>> for some pure python swig internal definitions) after the "import _wc".
> > >>
> > >>> I've figured out the problem: If we're using a threaded APR, and we
> > >>> import libsvn._wc before importing libsvn._core, the
> > >>> svn_swig_release_py_lock function will run before libsvn._core has had
> > >>> a chance to initialize APR.
> > >>
> > >> I was do not have a threaded APR on my primary machine, so I've now
> > >> compiled Subversion on a Linux system which does have threaded APR:
> > >>
> > >> Results:
> > >>
> > >>>>> import svn.wc
> > >> Initializing libsvn._wc
> > >> Initializing libsvn._core
> > >> Initializing libsvn_swig_py threadkey
> > >>>>> # no crash
> > >>
> > >> (messages produced by some strategically placed fprintf(stderr, ...) in
> > >> the
> > >> C code)
> > >>
> > >> [Tests done with r16474]
> > >>
> > >> Thanks for reverting the earlier workaround.
> > >> Hope you have luck trying to trace the cause of the crash, because it
> > >> looks
> > >> like a threaded APR is not the cause.
> > >
> > > Here's some crash logs from python2.
> > > (I added a few helpful printf() statements.)
> > >
> > > Here's an example crash log:
> > >
> > >>>> import libsvn.wc
> > > Initializing libsvn._wc
> > > Initializing libsvn._core
> > > Calling apr_initialize() from libsvn._core
> > > Initializing libsvn_swig_py thread key
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x40314567 in apr_pool_create_ex () from
> > > /h/46/james/lib/libsvn_swig_py-1.so.0 (gdb) up
> > > #1 0x402fbe3b in svn_swig_py_release_py_lock ()
> > > at
> > > /nobackup/clgrp/james/trunk/subversion/bindings/swig/python/libsvn_swig_
> > > y/swigutil_py.c:78 78 apr_pool_create(&_saved_thread_pool, NULL);
> > > (gdb) up
> > > #2 0x4021b4fd in _wrap_svn_swig_init_asp_dot_net_hack (self=0x0,
> > > args=0x8105844) at subversion/bindings/swig/python/svn_wc.c:23044
> > > 23044 svn_swig_py_release_py_lock();
> > > (gdb) up
> > > #3 0x080cd299 in PyCFunction_Call ()
> > >
> > > Here's another crash log:
> > >>>> import svn.repos
> > > Initializing libsvn._core
> > > Calling apr_initialize() from libsvn._core
> > > Initializing libsvn_swig_py thread key
> > > (no debugging symbols found)...
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x40300567 in apr_pool_create_ex () from
> > > /h/46/james/lib/libsvn_swig_py-1.so.0 (gdb) up
> > > #1 0x402e7e3b in svn_swig_py_release_py_lock ()
> > > at
> > > /nobackup/clgrp/james/trunk/subversion/bindings/swig/python/libsvn_swig_
> > > y/swigutil_py.c:78 78 apr_pool_create(&_saved_thread_pool, NULL);
> > > (gdb) up
> > > #2 0x40762d34 in _wrap_svn_pool_create (self=0x0, args=0x8105844)
> > > at subversion/bindings/swig/python/core.c:7638
> > > 7638 svn_swig_py_release_py_lock();
> > > (gdb) up
> > > #3 0x080cd299 in PyCFunction_Call ()
> > > (gdb)
> > >
> > >
> > > Here's some test cases:
> > > NO CRASH: import libsvn.core; import libsvn.wc
> > > CRASH: import libsvn.wc
> > > NO CRASH: import libsvn.repos
> > > CRASH: import libsvn.repos; import libsvn.core; import libsvn.wc
> > > CRASH: import svn.repos
> > > NO CRASH: import libsvn.fs
> > > CRASH: import svn.fs
> > >
> > > NOTE:
> > > If you use the patch I attached earlier in this thread (which adjusts
> > > the location of the apr_initialize call) then everything works fine.
> > > I'm not sure why, though -- clearly, from the above output, you can
> > > see that APR was already initialized by the time we arrived in
> > > svn_swig_release_py_lock.
> >
> > How bizarre!
> > Perhaps running against an APR with debug symbols might bring something
> > useful in gdb?
> Max, are you using a static or a dynamic build of APR?
>
> I'm using a static build of APR. Does that mean that C/Python module
> (libsvn._core, libsvn._wc, etc) has a separate copy of the internal
> APR datastructures? If so, then it might be a good idea for us to
> separately initialize APR in each module.
>
> To test this theory, I added apr_initialize and apr_terminate calls to
> "svn_global.swg", so that each and every Python module separately
> initializes and terminates APR. This fixed the problem.
Here's a debug run which shows the problem: the static variable
global_pool is NULL in the context of libsvn_swig_py, because
apr_initialize was only called in libsvn._core, while libsvn_swig_py
was first loaded by libsvn._wc.
Python 2.2.2 (#1, Jan 30 2003, 21:26:22)
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import libsvn.wc
apr_pool_create_ex(): global_pool=0, parent=0, allocator=81d0108
apr_pool_create_ex(): global_pool=81d4ba8, parent=0, allocator=0
apr_pool_create_ex(): global_pool=0, parent=0, allocator=0
(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x40345b62 in apr_pool_create_ex (newpool=0x403e2110, parent=0x0, abort_fn=0,
allocator=0x0) at apr_pools.c:806
806 allocator = parent->allocator;
(gdb) print global_pool
$1 = (struct apr_pool_t *) 0x0
(gdb) print parent
$2 = (struct apr_pool_t *) 0x0
(gdb) print allocator
$3 = (struct apr_allocator_t *) 0x0
(gdb) up
#1 0x4030074d in svn_swig_py_release_py_lock ()
at /nobackup/clgrp/james/trunk/subversion/bindings/swig/python/libsvn_swig_p
y/swigutil_py.c:77
77 apr_pool_create(&_saved_thread_pool, NULL);
(gdb) up
#2 0x40212a37 in _wrap_svn_swig_init_asp_dot_net_hack (self=0x0,
args=0x8105844) at subversion/bindings/swig/python/svn_wc.c:23044
23044 svn_swig_py_release_py_lock();
(gdb) up
#3 0x080cd299 in PyCFunction_Call ()
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 5 17:57:44 2005