[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r16449 - trunk/build/generator

From: David James <james82_at_gmail.com>
Date: 2005-10-05 07:46:05 CEST

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.

(Max, what version of APR are you using on your Linux box? I'm using 0.9.6.)

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 07:46:50 2005

This is an archived mail posted to the Subversion Dev mailing list.