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, what version of APR are you using on your Linux box? I'm using
> 0.9.6.)
0.9.6 too - I'm using Debian stable.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 5 10:02:56 2005