You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Alexey Neyman <st...@att.net> on 2014/09/11 04:05:36 UTC
Problem with subversion-perl RPMs from WanDisco?
Hi all,
I tried to update subversion to 1.8.10 on a freshly installed CentOS 6.5 and
noticed that an attempt to use Perl bindings has failed due to an undefined
symbol in the libsvn_swig_perl library: svn_swig_pl_get_current_pool
$ readelf -Ws /tmp/usr/lib64/libsvn_swig_perl-1.so.0 | grep svn_swig_pl_get_
79: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND
svn_swig_pl_get_current_pool
This symbol is defined in the library packaged into 1.9.0-alpha2 RPMs, but not
in any 1.8.x/1.7.x RPMs.
I have also tried on another machin - it originally had CentOS 6.0 installed +
partially upgraded. There, the Subversion Perl bindings from WanDisco's RPM
just coredump in Repos::Open - I am not sure if it is the same issue or not.
It works with the original CentOS version of subversion-perl (1.6.x).
Regards,
Alexey.
Re: Problem with subversion-perl RPMs from WanDisco?
Posted by Alexey Neyman <st...@att.net>.
On Wednesday, September 17, 2014 04:49:02 pm Nico Kadel-Garcia wrote:
> >> I cannot try stock CentOS, as they don't have 1.8.x available.
> >>
> >> I did try building and installing 1.8.10 from source on the same
> >> machine, and it works fine. So, it doesn't look like a version-specific
> >> issue - rather, like a build environment issue for WANdisco
> >> subversion-perl RPMs.
> >>
> >> Is it possible that the build environment changed between 1.8.0 and
> >> 1.8.1?
> >
> > FWIW, I installed all the updates on this test machine and Perl bindings
> > still crash.
> >
> > Does anyone else use Perl bindings from that WanDisco RPMs? Can anyone
> > verify that it works using a simple testcase below on a CentOS 6.x?
>
> Can't speak to what they have there. My github hosted RPM building
> tools at https://github.com/nkadel/subversion-1.8.x-srpm don't seem to
> have this problem.
That's nice to know, but I would like to avoid installing a build machine for
creating binary RPMs from SRPM specs if possible. If you look at the quote
above, I already mentioned that Subversion built from sources does not have
this problem; the problem is with *binary* RPMs offered through
opensource.wandisco.com.
Regards,
Alexey.
Re: Problem with subversion-perl RPMs from WanDisco?
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Wed, Sep 17, 2014 at 2:29 PM, Alexey Neyman <st...@att.net> wrote:
> On Friday, September 12, 2014 02:30:08 pm Alexey Neyman wrote:
>> On Friday, September 12, 2014 01:07:53 pm Ben Reser wrote:
>> > On 9/12/14 12:16 PM, Alexey Neyman wrote:
>> > > I did a bit of bisection, and it turns out that 1.8.0 was working
>> > > properly, but 1.8.1 and higher all segfault as described above.
>> > >
>> > > Hope that helps.
>> >
>> > With the WANdisco builds or any builds? The only differences between
>> > 1.8.0 and 1.8.1 that impacts the Perl bindings in any way was shutting
>> > up a bunch of compiler warnings about the _ symbol (which Perl defines
>> > in their header files and SVN also uses internally for different
>> > purposes) and a bunch of documentation changes. Neither of which should
>> > have any functional difference.
>> >
>> > If you're seeing this with the WANdisco builds I think this is something
>> > wrong with those builds, which has been my inclination in looking into
>> > this.
>>
>> I cannot try stock CentOS, as they don't have 1.8.x available.
>>
>> I did try building and installing 1.8.10 from source on the same machine,
>> and it works fine. So, it doesn't look like a version-specific issue -
>> rather, like a build environment issue for WANdisco subversion-perl RPMs.
>>
>> Is it possible that the build environment changed between 1.8.0 and 1.8.1?
>
> FWIW, I installed all the updates on this test machine and Perl bindings still
> crash.
>
> Does anyone else use Perl bindings from that WanDisco RPMs? Can anyone verify
> that it works using a simple testcase below on a CentOS 6.x?
Can't speak to what they have there. My github hosted RPM building
tools at https://github.com/nkadel/subversion-1.8.x-srpm don't seem to
have this problem.
Re: Problem with subversion-perl RPMs from WanDisco?
Posted by Alexey Neyman <st...@att.net>.
On Friday, September 12, 2014 02:30:08 pm Alexey Neyman wrote:
> On Friday, September 12, 2014 01:07:53 pm Ben Reser wrote:
> > On 9/12/14 12:16 PM, Alexey Neyman wrote:
> > > I did a bit of bisection, and it turns out that 1.8.0 was working
> > > properly, but 1.8.1 and higher all segfault as described above.
> > >
> > > Hope that helps.
> >
> > With the WANdisco builds or any builds? The only differences between
> > 1.8.0 and 1.8.1 that impacts the Perl bindings in any way was shutting
> > up a bunch of compiler warnings about the _ symbol (which Perl defines
> > in their header files and SVN also uses internally for different
> > purposes) and a bunch of documentation changes. Neither of which should
> > have any functional difference.
> >
> > If you're seeing this with the WANdisco builds I think this is something
> > wrong with those builds, which has been my inclination in looking into
> > this.
>
> I cannot try stock CentOS, as they don't have 1.8.x available.
>
> I did try building and installing 1.8.10 from source on the same machine,
> and it works fine. So, it doesn't look like a version-specific issue -
> rather, like a build environment issue for WANdisco subversion-perl RPMs.
>
> Is it possible that the build environment changed between 1.8.0 and 1.8.1?
FWIW, I installed all the updates on this test machine and Perl bindings still
crash.
Does anyone else use Perl bindings from that WanDisco RPMs? Can anyone verify
that it works using a simple testcase below on a CentOS 6.x?
[[[
cat >/tmp/1.pl <<'EOF'
#!/usr/bin/perl
use SVN::Core;
use SVN::Repos;
die "Usage: 1.pl REPO TXN" unless $#ARGV == 0;
my $repo = SVN::Repos::open($ARGV[0]) or die "Cannot open repo " . $ARGV[0];
exit 0;
EOF
chmod +x /tmp/1.pl
svnadmin create /tmp/testrepo
/tmp/1.pl /tmp/testrepo
]]]
Regards,
Alexey.
Re: Problem with subversion-perl RPMs from WanDisco?
Posted by Alexey Neyman <st...@att.net>.
On Friday, September 12, 2014 01:07:53 pm Ben Reser wrote:
> On 9/12/14 12:16 PM, Alexey Neyman wrote:
> > I did a bit of bisection, and it turns out that 1.8.0 was working
> > properly, but 1.8.1 and higher all segfault as described above.
> >
> > Hope that helps.
>
> With the WANdisco builds or any builds? The only differences between 1.8.0
> and 1.8.1 that impacts the Perl bindings in any way was shutting up a
> bunch of compiler warnings about the _ symbol (which Perl defines in their
> header files and SVN also uses internally for different purposes) and a
> bunch of documentation changes. Neither of which should have any
> functional difference.
>
> If you're seeing this with the WANdisco builds I think this is something
> wrong with those builds, which has been my inclination in looking into
> this.
I cannot try stock CentOS, as they don't have 1.8.x available.
I did try building and installing 1.8.10 from source on the same machine, and
it works fine. So, it doesn't look like a version-specific issue - rather,
like a build environment issue for WANdisco subversion-perl RPMs.
Is it possible that the build environment changed between 1.8.0 and 1.8.1?
Regards,
Alexey.
Re: Problem with subversion-perl RPMs from WanDisco?
Posted by Ben Reser <be...@reser.org>.
On 9/12/14 12:16 PM, Alexey Neyman wrote:
> I did a bit of bisection, and it turns out that 1.8.0 was working properly,
> but 1.8.1 and higher all segfault as described above.
>
> Hope that helps.
With the WANdisco builds or any builds? The only differences between 1.8.0 and
1.8.1 that impacts the Perl bindings in any way was shutting up a bunch of
compiler warnings about the _ symbol (which Perl defines in their header files
and SVN also uses internally for different purposes) and a bunch of
documentation changes. Neither of which should have any functional difference.
If you're seeing this with the WANdisco builds I think this is something wrong
with those builds, which has been my inclination in looking into this.
Re: Problem with subversion-perl RPMs from WanDisco?
Posted by Alexey Neyman <st...@att.net>.
On Friday, September 12, 2014 12:06:27 pm Alexey Neyman wrote:
> On Friday, September 12, 2014 11:57:14 am Alexey Neyman wrote:
> > On Friday, September 12, 2014 11:53:37 am Philip Martin wrote:
> > > Alexey Neyman <st...@att.net> writes:
> > > > 0x00007ffff138af10 in ?? ()
> > > > (gdb) bt
> > > > #0 0x00007ffff138af10 in ?? ()
> > > > #1 0x0000003bba01899e in run_cleanups (pool=0x8d7828) at
> > > > memory/unix/apr_pools.c:2314
> > > > #2 apr_pool_destroy (pool=0x8d7828) at memory/unix/apr_pools.c:782
> > > > #3 0x0000003bba018975 in apr_pool_destroy (pool=0x7e1498) at
> > > > memory/unix/apr_pools.c:779
> > > > #4 0x0000003bba018b84 in apr_pool_terminate () at
> > > > memory/unix/apr_pools.c:605 #5 0x00007ffff1e5153d in
> > > > _wrap_apr_terminate (my_perl=<value optimized out>, cv=<value
> > > > optimized out>) at core.c:2590
> > > > #6 0x0000003ae0aa6815 in Perl_pp_entersub (my_perl=0x603010) at
> > > > pp_hot.c:2888 #7 0x0000003ae0aa4b06 in Perl_runops_standard
> > > > (my_perl=0x603010) at run.c:40 #8 0x0000003ae0a4c5df in Perl_call_sv
> > > > (my_perl=0x603010, sv=0x6c9190, flags=6) at perl.c:2721
> > > > #9 0x0000003ae0a4cb1d in Perl_call_list (my_perl=0x603010,
> > > > oldscope=1, paramList=0x6c9388) at perl.c:5276
> > > > #10 0x0000003ae0a4e947 in perl_destruct (my_perl=0x603010) at
> > > > perl.c:630 #11 0x0000000000400e01 in main (argc=3,
> > > > argv=0x7fffffffe5a8,
> > > > env=0x7fffffffe5c8) at perlmain.c:126
> > >
> > > The stacktrace may be more useful if you install the debuginfo packages
> > > for subversion, apr and apr-util.
> >
> > They are installed, as you might see in the frames #1..#4. Apparently, it
> > jumped somewhere outside of the function boundaries - so the frame #0
> > cannot determine the function name.
>
> Actually, the program counter at the time of the crash does not belong to
> any shared library
I did a bit of bisection, and it turns out that 1.8.0 was working properly,
but 1.8.1 and higher all segfault as described above.
Hope that helps.
Re: Problem with subversion-perl RPMs from WanDisco?
Posted by Alexey Neyman <st...@att.net>.
On Friday, September 12, 2014 11:57:14 am Alexey Neyman wrote:
> On Friday, September 12, 2014 11:53:37 am Philip Martin wrote:
> > Alexey Neyman <st...@att.net> writes:
> > > 0x00007ffff138af10 in ?? ()
> > > (gdb) bt
> > > #0 0x00007ffff138af10 in ?? ()
> > > #1 0x0000003bba01899e in run_cleanups (pool=0x8d7828) at
> > > memory/unix/apr_pools.c:2314
> > > #2 apr_pool_destroy (pool=0x8d7828) at memory/unix/apr_pools.c:782
> > > #3 0x0000003bba018975 in apr_pool_destroy (pool=0x7e1498) at
> > > memory/unix/apr_pools.c:779
> > > #4 0x0000003bba018b84 in apr_pool_terminate () at
> > > memory/unix/apr_pools.c:605 #5 0x00007ffff1e5153d in
> > > _wrap_apr_terminate (my_perl=<value optimized out>, cv=<value optimized
> > > out>) at core.c:2590
> > > #6 0x0000003ae0aa6815 in Perl_pp_entersub (my_perl=0x603010) at
> > > pp_hot.c:2888 #7 0x0000003ae0aa4b06 in Perl_runops_standard
> > > (my_perl=0x603010) at run.c:40 #8 0x0000003ae0a4c5df in Perl_call_sv
> > > (my_perl=0x603010, sv=0x6c9190, flags=6) at perl.c:2721
> > > #9 0x0000003ae0a4cb1d in Perl_call_list (my_perl=0x603010, oldscope=1,
> > > paramList=0x6c9388) at perl.c:5276
> > > #10 0x0000003ae0a4e947 in perl_destruct (my_perl=0x603010) at
> > > perl.c:630 #11 0x0000000000400e01 in main (argc=3,
> > > argv=0x7fffffffe5a8,
> > > env=0x7fffffffe5c8) at perlmain.c:126
> >
> > The stacktrace may be more useful if you install the debuginfo packages
> > for subversion, apr and apr-util.
>
> They are installed, as you might see in the frames #1..#4. Apparently, it
> jumped somewhere outside of the function boundaries - so the frame #0
> cannot determine the function name.
Actually, the program counter at the time of the crash does not belong to any shared library:
(gdb) bt
#0 0x00007fffefefff10 in ?? ()
#1 0x0000003bba01899e in run_cleanups (pool=0x8d7828) at memory/unix/apr_pools.c:2314
#2 apr_pool_destroy (pool=0x8d7828) at memory/unix/apr_pools.c:782
#3 0x0000003bba018975 in apr_pool_destroy (pool=0x7e1498) at memory/unix/apr_pools.c:779
#4 0x0000003bba018b84 in apr_pool_terminate () at memory/unix/apr_pools.c:605
#5 0x00007ffff1e5153d in _wrap_apr_terminate (my_perl=<value optimized out>, cv=<value optimized out>) at core.c:2590
#6 0x0000003ae0aa6815 in Perl_pp_entersub (my_perl=0x603010) at pp_hot.c:2888
#7 0x0000003ae0aa4b06 in Perl_runops_standard (my_perl=0x603010) at run.c:40
#8 0x0000003ae0a4c5df in Perl_call_sv (my_perl=0x603010, sv=0x6c9190, flags=6) at perl.c:2721
#9 0x0000003ae0a4cb1d in Perl_call_list (my_perl=0x603010, oldscope=1, paramList=0x6c9388) at perl.c:5276
#10 0x0000003ae0a4e947 in perl_destruct (my_perl=0x603010) at perl.c:630
#11 0x0000000000400e01 in main (argc=3, argv=0x7fffffffe5a8, env=0x7fffffffe5c8) at perlmain.c:126
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x0000003acd600b00 0x0000003acd6198eb Yes /lib64/ld-linux-x86-64.so.2
0x0000003ae0a34d10 0x0000003ae0b31688 Yes /usr/lib64/perl5/CORE/libperl.so
0x0000003acfa03930 0x0000003acfa12938 Yes /lib64/libresolv.so.2
0x0000003ade604070 0x0000003ade6119f8 Yes /lib64/libnsl.so.1
0x0000003acda00de0 0x0000003acda01998 Yes /lib64/libdl.so.2
0x0000003ace603e70 0x0000003ace643fb8 Yes /lib64/libm.so.6
0x0000003add600c00 0x0000003add6059a8 Yes /lib64/libcrypt.so.1
0x0000003adf200e10 0x0000003adf201688 Yes /lib64/libutil.so.1
0x0000003ace205760 0x0000003ace2110c8 Yes /lib64/libpthread.so.0
0x0000003acde1ea60 0x0000003acdf4024c Yes /lib64/libc.so.6
0x0000003add203c40 0x0000003add2539e8 Yes /lib64/libfreebl3.so
0x00007ffff1e49f10 0x00007ffff1ef9c68 Yes /usr/local/lib64/perl5/auto/SVN/_Core/_Core.so
0x00007ffff1bd1fd0 0x00007ffff1c18f58 Yes /usr/lib64/libsvn_client-1.so.0
0x00007ffff19b3af0 0x00007ffff19be218 Yes /usr/lib64/libsvn_delta-1.so.0
0x00007ffff17a9970 0x00007ffff17ad198 Yes /usr/lib64/libsvn_fs-1.so.0
0x00007ffff159ce40 0x00007ffff15a36e8 Yes /usr/lib64/libsvn_ra-1.so.0
0x00007ffff136e640 0x00007ffff138a5c8 Yes /usr/lib64/libsvn_repos-1.so.0
0x00007ffff10cb930 0x00007ffff113f688 Yes /usr/lib64/libsvn_wc-1.so.0
0x00007ffff0ea5c40 0x00007ffff0eb2a48 Yes /usr/lib64/libsvn_diff-1.so.0
0x00007ffff0bbc3e0 0x00007ffff0c65be8 Yes /usr/lib64/libsvn_subr-1.so.0
0x00007ffff0994ce0 0x00007ffff099a4d8 Yes /usr/lib64/libsvn_swig_perl-1.so.0
0x0000003acea02120 0x0000003acea0d3a8 Yes /lib64/libz.so.1
0x0000003bb9c091e0 0x0000003bb9c1c668 Yes /usr/lib64/libaprutil-1.so.0
0x0000003ad1603cd0 0x0000003ad161cc88 Yes /lib64/libexpat.so.1
0x0000003adc2286a0 0x0000003adc33e9d8 Yes /usr/lib64/libdb-4.7.so
0x0000003bba00b8f0 0x0000003bba023ab8 Yes /usr/lib64/libapr-1.so.0
0x00007ffff0790b40 0x00007ffff0791058 Yes /usr/lib64/libsvn_fs_util-1.so.0
0x0000003ad4a015a0 0x0000003ad4a02cc8 Yes /lib64/libuuid.so.1
0x00007ffff058ca30 0x00007ffff058e958 Yes /usr/lib64/perl5/auto/IO/IO.so
0x00007ffff0384620 0x00007ffff0389af8 Yes /usr/lib64/perl5/auto/List/Util/Util.so
0x00007ffff011afe0 0x00007ffff015c1e8 Yes /usr/local/lib64/perl5/auto/SVN/_Repos/_Repos.so
Re: Problem with subversion-perl RPMs from WanDisco?
Posted by Alexey Neyman <st...@att.net>.
On Friday, September 12, 2014 11:53:37 am Philip Martin wrote:
> Alexey Neyman <st...@att.net> writes:
> > 0x00007ffff138af10 in ?? ()
> > (gdb) bt
> > #0 0x00007ffff138af10 in ?? ()
> > #1 0x0000003bba01899e in run_cleanups (pool=0x8d7828) at
> > memory/unix/apr_pools.c:2314
> > #2 apr_pool_destroy (pool=0x8d7828) at memory/unix/apr_pools.c:782
> > #3 0x0000003bba018975 in apr_pool_destroy (pool=0x7e1498) at
> > memory/unix/apr_pools.c:779
> > #4 0x0000003bba018b84 in apr_pool_terminate () at
> > memory/unix/apr_pools.c:605 #5 0x00007ffff1e5153d in
> > _wrap_apr_terminate (my_perl=<value optimized out>, cv=<value optimized
> > out>) at core.c:2590
> > #6 0x0000003ae0aa6815 in Perl_pp_entersub (my_perl=0x603010) at
> > pp_hot.c:2888 #7 0x0000003ae0aa4b06 in Perl_runops_standard
> > (my_perl=0x603010) at run.c:40 #8 0x0000003ae0a4c5df in Perl_call_sv
> > (my_perl=0x603010, sv=0x6c9190, flags=6) at perl.c:2721
> > #9 0x0000003ae0a4cb1d in Perl_call_list (my_perl=0x603010, oldscope=1,
> > paramList=0x6c9388) at perl.c:5276
> > #10 0x0000003ae0a4e947 in perl_destruct (my_perl=0x603010) at perl.c:630
> > #11 0x0000000000400e01 in main (argc=3, argv=0x7fffffffe5a8,
> > env=0x7fffffffe5c8) at perlmain.c:126
>
> The stacktrace may be more useful if you install the debuginfo packages
> for subversion, apr and apr-util.
They are installed, as you might see in the frames #1..#4. Apparently, it
jumped somewhere outside of the function boundaries - so the frame #0 cannot
determine the function name.
Re: Problem with subversion-perl RPMs from WanDisco?
Posted by Philip Martin <ph...@wandisco.com>.
Alexey Neyman <st...@att.net> writes:
> 0x00007ffff138af10 in ?? ()
> (gdb) bt
> #0 0x00007ffff138af10 in ?? ()
> #1 0x0000003bba01899e in run_cleanups (pool=0x8d7828) at
> memory/unix/apr_pools.c:2314
> #2 apr_pool_destroy (pool=0x8d7828) at memory/unix/apr_pools.c:782
> #3 0x0000003bba018975 in apr_pool_destroy (pool=0x7e1498) at
> memory/unix/apr_pools.c:779
> #4 0x0000003bba018b84 in apr_pool_terminate () at memory/unix/apr_pools.c:605
> #5 0x00007ffff1e5153d in _wrap_apr_terminate (my_perl=<value optimized out>,
> cv=<value optimized out>) at core.c:2590
> #6 0x0000003ae0aa6815 in Perl_pp_entersub (my_perl=0x603010) at pp_hot.c:2888
> #7 0x0000003ae0aa4b06 in Perl_runops_standard (my_perl=0x603010) at run.c:40
> #8 0x0000003ae0a4c5df in Perl_call_sv (my_perl=0x603010, sv=0x6c9190,
> flags=6) at perl.c:2721
> #9 0x0000003ae0a4cb1d in Perl_call_list (my_perl=0x603010, oldscope=1,
> paramList=0x6c9388) at perl.c:5276
> #10 0x0000003ae0a4e947 in perl_destruct (my_perl=0x603010) at perl.c:630
> #11 0x0000000000400e01 in main (argc=3, argv=0x7fffffffe5a8,
> env=0x7fffffffe5c8) at perlmain.c:126
The stacktrace may be more useful if you install the debuginfo packages
for subversion, apr and apr-util.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: Problem with subversion-perl RPMs from WanDisco?
Posted by Alexey Neyman <st...@att.net>.
On Friday, September 12, 2014 11:16:12 am Philip Martin wrote:
> Alexey Neyman <st...@att.net> writes:
> > Rather, I think, it is that the libsvn_swig_perl-1.so.0 does not list the
>
> > _Core.so as a dependency:
> I don't think that's the way it works. When Perl uses a module such as
> SVN::Repos then Perl itself knows to uses SVN::Core as a dependency.
> That causes the shared objects _Repos.so and _Core.so to be loaded. You
> should see that _Core.so has libsvn_swig_perl-1.so as a dependency.
Apparently it doesn't know that - see below.
> > If I pre-load the library, though, it fails differently:
> >
> > $ LD_PRELOAD=/usr/local/lib64/perl5/auto/SVN/_Core/_Core.so /tmp/1.pl
> > /repo Can't locate object method "new_default" via package "SVN::Pool"
> > (perhaps you forgot to load "SVN::Pool"?) at /tmp/1.pl line 6.
>
> I'm not sure LD_PRELOAD is the right way to do it as that might bypass
> the full Perl module load mechanism. I think you should try setting
> @INC, perhaps via
>
> use lib '/usr/local/lib64/perl5';
Unfortunately, this does not work. What works (at least getting it past the
point of loading the library) is explicit 'use SVN::Core;' before 'use
SVN::Repos'. But, I have verified this is an issue with the stock CentOS
packages (1.6.11), so it seems to be a generic issue. I removed too much when
reducing the test case. So, the question is, should SVN::Repos load SVN::Core
automatically?
However, it then segfaults in a shared library.
[aneyman@localhost ~]$ gdb /usr/bin/perl
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/perl...Reading symbols from
/usr/lib/debug/usr/bin/suidperl.debug...done.
done.
(gdb) r /tmp/1.pl /svn/testrepo
Starting program: /usr/bin/perl /tmp/1.pl /svn/testrepo
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff138af10 in ?? ()
(gdb) bt
#0 0x00007ffff138af10 in ?? ()
#1 0x0000003bba01899e in run_cleanups (pool=0x8d7828) at
memory/unix/apr_pools.c:2314
#2 apr_pool_destroy (pool=0x8d7828) at memory/unix/apr_pools.c:782
#3 0x0000003bba018975 in apr_pool_destroy (pool=0x7e1498) at
memory/unix/apr_pools.c:779
#4 0x0000003bba018b84 in apr_pool_terminate () at memory/unix/apr_pools.c:605
#5 0x00007ffff1e5153d in _wrap_apr_terminate (my_perl=<value optimized out>,
cv=<value optimized out>) at core.c:2590
#6 0x0000003ae0aa6815 in Perl_pp_entersub (my_perl=0x603010) at pp_hot.c:2888
#7 0x0000003ae0aa4b06 in Perl_runops_standard (my_perl=0x603010) at run.c:40
#8 0x0000003ae0a4c5df in Perl_call_sv (my_perl=0x603010, sv=0x6c9190,
flags=6) at perl.c:2721
#9 0x0000003ae0a4cb1d in Perl_call_list (my_perl=0x603010, oldscope=1,
paramList=0x6c9388) at perl.c:5276
#10 0x0000003ae0a4e947 in perl_destruct (my_perl=0x603010) at perl.c:630
#11 0x0000000000400e01 in main (argc=3, argv=0x7fffffffe5a8,
env=0x7fffffffe5c8) at perlmain.c:126
[[[ 1.pl ]]]
[aneyman@localhost ~]$ cat /tmp/1.pl
#!/usr/bin/perl
use SVN::Core;
use SVN::Repos;
die "Usage: 1.pl REPO TXN" unless $#ARGV == 0;
my $repo = SVN::Repos::open($ARGV[0]) or die "Cannot open repo " . $ARGV[0];
exit 0;
]]]
The same script works fine with the stock CentOS bindings.
Regards,
Alexey.
Re: Problem with subversion-perl RPMs from WanDisco?
Posted by Ben Reser <be...@reser.org>.
On 9/12/14 11:54 AM, Branko Čibej wrote:
> On 12.09.2014 20:37, Philip Martin wrote:
>> Philip Martin <ph...@wandisco.com> writes:
>>
>>> Alexey Neyman <st...@att.net> writes:
>>>
>>>> Rather, I think, it is that the libsvn_swig_perl-1.so.0 does not list the
>>>> _Core.so as a dependency:
>>> I don't think that's the way it works. When Perl uses a module such as
>>> SVN::Repos then Perl itself knows to uses SVN::Core as a dependency.
>>> That causes the shared objects _Repos.so and _Core.so to be loaded. You
>>> should see that _Core.so has libsvn_swig_perl-1.so as a dependency.
>> After a bit of testing on my machine it appears that loading SVN::Repos
>> doesn't load SVN::Core automatically. I can reproduce your error on my
>> system, and I can solve it by adding 'use SVN::Core' to the script.
>
> All our Perl bindings tests explicitly load SVN::Core. I'm not sure what
> the intent of the packaging was initially, but it appears that the
> cross-module dependencies aren't exposed to the module loader; so
> loading SVN::Core is pretty much required in any script that uses our
> Perl bindings.
>
> I think this is more of a mess than a bug. :)
The Perl bindings have a different layout that breaks what most other bindings
refer to as core into two libraries.
SVN::Base (which is the raw symbols that the created by swig and is needed by
every module in order to bootstrap, specifically it loads the _Module.so
libraries that Alexey and Philip are talking about above.).
SVN::Core (which handles some initialization and wrapping of our basic types
e.g. streams and pools).
SVN::Client and SVN::Wc both load SVN::Core for you. Other modules do not and
their examples in their documentation show you loading SVN::Core. I'd bet that
I'm the one that added the loading of SVN::Core to SVN::Client and SVN::Wc
since I was trying to make them friendly to use.
The other modules have never really been made friendly to users.
We've done something really weird with svn_swig_pl_get_current_pool() that I
haven't quiet wrapped my head around yet.
But yes I agree this is a mess.
Re: Problem with subversion-perl RPMs from WanDisco?
Posted by Branko Čibej <br...@wandisco.com>.
On 12.09.2014 20:37, Philip Martin wrote:
> Philip Martin <ph...@wandisco.com> writes:
>
>> Alexey Neyman <st...@att.net> writes:
>>
>>> Rather, I think, it is that the libsvn_swig_perl-1.so.0 does not list the
>>> _Core.so as a dependency:
>> I don't think that's the way it works. When Perl uses a module such as
>> SVN::Repos then Perl itself knows to uses SVN::Core as a dependency.
>> That causes the shared objects _Repos.so and _Core.so to be loaded. You
>> should see that _Core.so has libsvn_swig_perl-1.so as a dependency.
> After a bit of testing on my machine it appears that loading SVN::Repos
> doesn't load SVN::Core automatically. I can reproduce your error on my
> system, and I can solve it by adding 'use SVN::Core' to the script.
All our Perl bindings tests explicitly load SVN::Core. I'm not sure what
the intent of the packaging was initially, but it appears that the
cross-module dependencies aren't exposed to the module loader; so
loading SVN::Core is pretty much required in any script that uses our
Perl bindings.
I think this is more of a mess than a bug. :)
-- Brane
Re: Problem with subversion-perl RPMs from WanDisco?
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@wandisco.com> writes:
> Alexey Neyman <st...@att.net> writes:
>
>> Rather, I think, it is that the libsvn_swig_perl-1.so.0 does not list the
>> _Core.so as a dependency:
>
> I don't think that's the way it works. When Perl uses a module such as
> SVN::Repos then Perl itself knows to uses SVN::Core as a dependency.
> That causes the shared objects _Repos.so and _Core.so to be loaded. You
> should see that _Core.so has libsvn_swig_perl-1.so as a dependency.
After a bit of testing on my machine it appears that loading SVN::Repos
doesn't load SVN::Core automatically. I can reproduce your error on my
system, and I can solve it by adding 'use SVN::Core' to the script.
--
Philip
Re: Problem with subversion-perl RPMs from WanDisco?
Posted by Philip Martin <ph...@wandisco.com>.
Alexey Neyman <st...@att.net> writes:
> Rather, I think, it is that the libsvn_swig_perl-1.so.0 does not list the
> _Core.so as a dependency:
I don't think that's the way it works. When Perl uses a module such as
SVN::Repos then Perl itself knows to uses SVN::Core as a dependency.
That causes the shared objects _Repos.so and _Core.so to be loaded. You
should see that _Core.so has libsvn_swig_perl-1.so as a dependency.
> If I pre-load the library, though, it fails differently:
>
> $ LD_PRELOAD=/usr/local/lib64/perl5/auto/SVN/_Core/_Core.so /tmp/1.pl /repo
> Can't locate object method "new_default" via package "SVN::Pool" (perhaps you
> forgot to load "SVN::Pool"?) at /tmp/1.pl line 6.
I'm not sure LD_PRELOAD is the right way to do it as that might bypass
the full Perl module load mechanism. I think you should try setting
@INC, perhaps via
use lib '/usr/local/lib64/perl5';
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: Problem with subversion-perl RPMs from WanDisco?
Posted by Alexey Neyman <st...@att.net>.
On Friday, September 12, 2014 09:45:32 am Philip Martin wrote:
> Alexey Neyman <st...@att.net> writes:
> > I tried to update subversion to 1.8.10 on a freshly installed CentOS 6.5
> > and noticed that an attempt to use Perl bindings has failed due to an
> > undefined symbol in the libsvn_swig_perl library:
> > svn_swig_pl_get_current_pool
> >
> > $ readelf -Ws /tmp/usr/lib64/libsvn_swig_perl-1.so.0 | grep
> > svn_swig_pl_get_
> >
> > 79: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND
> >
> > svn_swig_pl_get_current_pool
>
> I see that the 1.8 WANdisco package installs some files into
> /usr/local/lib64. The file
>
> /usr/local/lib64/perl5/auto/SVN/_Core/_Core.so
>
> is the one that defines your missing symbol. Perhaps the problem is
> that the way you are invoking Perl means it does not load files from
> /usr/local?
Rather, I think, it is that the libsvn_swig_perl-1.so.0 does not list the
_Core.so as a dependency:
$ ldd /usr/lib64/libsvn_swig_perl-1.so
linux-vdso.so.1 => (0x00007fffea3ff000)
libsvn_delta-1.so.0 => /usr/lib64/libsvn_delta-1.so.0
(0x00007f31ce700000)
libsvn_subr-1.so.0 => /usr/lib64/libsvn_subr-1.so.0
(0x00007f31ce3fa000)
libz.so.1 => /lib64/libz.so.1 (0x00007f31ce1cc000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f31cdfc8000)
libaprutil-1.so.0 => /usr/lib64/libaprutil-1.so.0 (0x00007f31cdda4000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f31cdb6c000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f31cd944000)
libdb-4.7.so => /usr/lib64/libdb-4.7.so (0x00007f31cd5d0000)
libapr-1.so.0 => /usr/lib64/libapr-1.so.0 (0x00007f31cd3a3000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f31cd186000)
libc.so.6 => /lib64/libc.so.6 (0x00007f31ccdf2000)
/lib64/ld-linux-x86-64.so.2 (0x0000003acd600000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f31ccbed000)
libfreebl3.so => /usr/lib64/libfreebl3.so (0x00007f31cc976000)
If I pre-load the library, though, it fails differently:
$ LD_PRELOAD=/usr/local/lib64/perl5/auto/SVN/_Core/_Core.so /tmp/1.pl /repo
Can't locate object method "new_default" via package "SVN::Pool" (perhaps you
forgot to load "SVN::Pool"?) at /tmp/1.pl line 6.
[[[ 1.pl
#!/usr/bin/perl
use SVN::Repos;
die "Usage: 1.pl REPO" unless $#ARGV == 0;
my $repo = SVN::Repos::open($ARGV[0]) or die "Cannot open repo " . $ARGV[0];
exit 0;
]]]
> You might be able to set LD_DEBUG to diagnose the problem,
> something like
>
> LD_DEBUG=libs perl file.pl
Just as I said above, it does not even try to search for _Core.so:
$ LD_DEBUG=libs /tmp/1.pl /repo 2>&1 | grep _Core
$
As a side question, why does this package install stuff into both /usr/lib and
/usr/local/lib?
Regards,
Alexey.
>
> (run any executable with LD_DEBUG=help to see other options).
>
> > This symbol is defined in the library packaged into 1.9.0-alpha2 RPMs,
> > but not in any 1.8.x/1.7.x RPMs.
>
> The handling of the symbol changed in 1.9.
Re: Problem with subversion-perl RPMs from WanDisco?
Posted by Philip Martin <ph...@wandisco.com>.
Alexey Neyman <st...@att.net> writes:
> I tried to update subversion to 1.8.10 on a freshly installed CentOS 6.5 and
> noticed that an attempt to use Perl bindings has failed due to an undefined
> symbol in the libsvn_swig_perl library: svn_swig_pl_get_current_pool
>
> $ readelf -Ws /tmp/usr/lib64/libsvn_swig_perl-1.so.0 | grep svn_swig_pl_get_
> 79: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND
> svn_swig_pl_get_current_pool
I see that the 1.8 WANdisco package installs some files into
/usr/local/lib64. The file
/usr/local/lib64/perl5/auto/SVN/_Core/_Core.so
is the one that defines your missing symbol. Perhaps the problem is
that the way you are invoking Perl means it does not load files from
/usr/local? You might be able to set LD_DEBUG to diagnose the problem,
something like
LD_DEBUG=libs perl file.pl
(run any executable with LD_DEBUG=help to see other options).
> This symbol is defined in the library packaged into 1.9.0-alpha2 RPMs,
> but not in any 1.8.x/1.7.x RPMs.
The handling of the symbol changed in 1.9.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*