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.
Cheers,
David
--
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 16:01:11 2005