Re: Problem with subversion-perl RPMs from WanDisco?
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?
On Wed, Sep 17, 2014 at 2:29 PM, Alexey Neyman sti...@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?
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?
Alexey Neyman sti...@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: 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*
Re: Problem with subversion-perl RPMs from WanDisco?
On Friday, September 12, 2014 09:45:32 am Philip Martin wrote: Alexey Neyman sti...@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: 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 = (0x7fffea3ff000) libsvn_delta-1.so.0 = /usr/lib64/libsvn_delta-1.so.0 (0x7f31ce70) libsvn_subr-1.so.0 = /usr/lib64/libsvn_subr-1.so.0 (0x7f31ce3fa000) libz.so.1 = /lib64/libz.so.1 (0x7f31ce1cc000) libdl.so.2 = /lib64/libdl.so.2 (0x7f31cdfc8000) libaprutil-1.so.0 = /usr/lib64/libaprutil-1.so.0 (0x7f31cdda4000) libcrypt.so.1 = /lib64/libcrypt.so.1 (0x7f31cdb6c000) libexpat.so.1 = /lib64/libexpat.so.1 (0x7f31cd944000) libdb-4.7.so = /usr/lib64/libdb-4.7.so (0x7f31cd5d) libapr-1.so.0 = /usr/lib64/libapr-1.so.0 (0x7f31cd3a3000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f31cd186000) libc.so.6 = /lib64/libc.so.6 (0x7f31ccdf2000) /lib64/ld-linux-x86-64.so.2 (0x003acd60) libuuid.so.1 = /lib64/libuuid.so.1 (0x7f31ccbed000) libfreebl3.so = /usr/lib64/libfreebl3.so (0x7f31cc976000) 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 21 | 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?
Alexey Neyman sti...@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?
Philip Martin philip.mar...@wandisco.com writes: Alexey Neyman sti...@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?
On Friday, September 12, 2014 11:16:12 am Philip Martin wrote: Alexey Neyman sti...@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. 0x7138af10 in ?? () (gdb) bt #0 0x7138af10 in ?? () #1 0x003bba01899e 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 0x003bba018975 in apr_pool_destroy (pool=0x7e1498) at memory/unix/apr_pools.c:779 #4 0x003bba018b84 in apr_pool_terminate () at memory/unix/apr_pools.c:605 #5 0x71e5153d in _wrap_apr_terminate (my_perl=value optimized out, cv=value optimized out) at core.c:2590 #6 0x003ae0aa6815 in Perl_pp_entersub (my_perl=0x603010) at pp_hot.c:2888 #7 0x003ae0aa4b06 in Perl_runops_standard (my_perl=0x603010) at run.c:40 #8 0x003ae0a4c5df in Perl_call_sv (my_perl=0x603010, sv=0x6c9190, flags=6) at perl.c:2721 #9 0x003ae0a4cb1d in Perl_call_list (my_perl=0x603010, oldscope=1, paramList=0x6c9388) at perl.c:5276 #10 0x003ae0a4e947 in perl_destruct (my_perl=0x603010) at perl.c:630 #11 0x00400e01 in main (argc=3, argv=0x7fffe5a8, env=0x7fffe5c8) 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?
Alexey Neyman sti...@att.net writes: 0x7138af10 in ?? () (gdb) bt #0 0x7138af10 in ?? () #1 0x003bba01899e 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 0x003bba018975 in apr_pool_destroy (pool=0x7e1498) at memory/unix/apr_pools.c:779 #4 0x003bba018b84 in apr_pool_terminate () at memory/unix/apr_pools.c:605 #5 0x71e5153d in _wrap_apr_terminate (my_perl=value optimized out, cv=value optimized out) at core.c:2590 #6 0x003ae0aa6815 in Perl_pp_entersub (my_perl=0x603010) at pp_hot.c:2888 #7 0x003ae0aa4b06 in Perl_runops_standard (my_perl=0x603010) at run.c:40 #8 0x003ae0a4c5df in Perl_call_sv (my_perl=0x603010, sv=0x6c9190, flags=6) at perl.c:2721 #9 0x003ae0a4cb1d in Perl_call_list (my_perl=0x603010, oldscope=1, paramList=0x6c9388) at perl.c:5276 #10 0x003ae0a4e947 in perl_destruct (my_perl=0x603010) at perl.c:630 #11 0x00400e01 in main (argc=3, argv=0x7fffe5a8, env=0x7fffe5c8) 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?
On 12.09.2014 20:37, Philip Martin wrote: Philip Martin philip.mar...@wandisco.com writes: Alexey Neyman sti...@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?
On Friday, September 12, 2014 11:53:37 am Philip Martin wrote: Alexey Neyman sti...@att.net writes: 0x7138af10 in ?? () (gdb) bt #0 0x7138af10 in ?? () #1 0x003bba01899e 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 0x003bba018975 in apr_pool_destroy (pool=0x7e1498) at memory/unix/apr_pools.c:779 #4 0x003bba018b84 in apr_pool_terminate () at memory/unix/apr_pools.c:605 #5 0x71e5153d in _wrap_apr_terminate (my_perl=value optimized out, cv=value optimized out) at core.c:2590 #6 0x003ae0aa6815 in Perl_pp_entersub (my_perl=0x603010) at pp_hot.c:2888 #7 0x003ae0aa4b06 in Perl_runops_standard (my_perl=0x603010) at run.c:40 #8 0x003ae0a4c5df in Perl_call_sv (my_perl=0x603010, sv=0x6c9190, flags=6) at perl.c:2721 #9 0x003ae0a4cb1d in Perl_call_list (my_perl=0x603010, oldscope=1, paramList=0x6c9388) at perl.c:5276 #10 0x003ae0a4e947 in perl_destruct (my_perl=0x603010) at perl.c:630 #11 0x00400e01 in main (argc=3, argv=0x7fffe5a8, env=0x7fffe5c8) 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?
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 sti...@att.net writes: 0x7138af10 in ?? () (gdb) bt #0 0x7138af10 in ?? () #1 0x003bba01899e 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 0x003bba018975 in apr_pool_destroy (pool=0x7e1498) at memory/unix/apr_pools.c:779 #4 0x003bba018b84 in apr_pool_terminate () at memory/unix/apr_pools.c:605 #5 0x71e5153d in _wrap_apr_terminate (my_perl=value optimized out, cv=value optimized out) at core.c:2590 #6 0x003ae0aa6815 in Perl_pp_entersub (my_perl=0x603010) at pp_hot.c:2888 #7 0x003ae0aa4b06 in Perl_runops_standard (my_perl=0x603010) at run.c:40 #8 0x003ae0a4c5df in Perl_call_sv (my_perl=0x603010, sv=0x6c9190, flags=6) at perl.c:2721 #9 0x003ae0a4cb1d in Perl_call_list (my_perl=0x603010, oldscope=1, paramList=0x6c9388) at perl.c:5276 #10 0x003ae0a4e947 in perl_destruct (my_perl=0x603010) at perl.c:630 #11 0x00400e01 in main (argc=3, argv=0x7fffe5a8, env=0x7fffe5c8) 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 0x7fffefefff10 in ?? () #1 0x003bba01899e 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 0x003bba018975 in apr_pool_destroy (pool=0x7e1498) at memory/unix/apr_pools.c:779 #4 0x003bba018b84 in apr_pool_terminate () at memory/unix/apr_pools.c:605 #5 0x71e5153d in _wrap_apr_terminate (my_perl=value optimized out, cv=value optimized out) at core.c:2590 #6 0x003ae0aa6815 in Perl_pp_entersub (my_perl=0x603010) at pp_hot.c:2888 #7 0x003ae0aa4b06 in Perl_runops_standard (my_perl=0x603010) at run.c:40 #8 0x003ae0a4c5df in Perl_call_sv (my_perl=0x603010, sv=0x6c9190, flags=6) at perl.c:2721 #9 0x003ae0a4cb1d in Perl_call_list (my_perl=0x603010, oldscope=1, paramList=0x6c9388) at perl.c:5276 #10 0x003ae0a4e947 in perl_destruct (my_perl=0x603010) at perl.c:630 #11 0x00400e01 in main (argc=3, argv=0x7fffe5a8, env=0x7fffe5c8) at perlmain.c:126 (gdb) info sharedlibrary FromTo Syms Read Shared Object Library 0x003acd600b00 0x003acd6198eb Yes /lib64/ld-linux-x86-64.so.2 0x003ae0a34d10 0x003ae0b31688 Yes /usr/lib64/perl5/CORE/libperl.so 0x003acfa03930 0x003acfa12938 Yes /lib64/libresolv.so.2 0x003ade604070 0x003ade6119f8 Yes /lib64/libnsl.so.1 0x003acda00de0 0x003acda01998 Yes /lib64/libdl.so.2 0x003ace603e70 0x003ace643fb8 Yes /lib64/libm.so.6 0x003add600c00 0x003add6059a8 Yes /lib64/libcrypt.so.1 0x003adf200e10 0x003adf201688 Yes /lib64/libutil.so.1 0x003ace205760 0x003ace2110c8 Yes /lib64/libpthread.so.0 0x003acde1ea60 0x003acdf4024c Yes /lib64/libc.so.6 0x003add203c40 0x003add2539e8 Yes /lib64/libfreebl3.so 0x71e49f10 0x71ef9c68 Yes /usr/local/lib64/perl5/auto/SVN/_Core/_Core.so 0x71bd1fd0 0x71c18f58 Yes /usr/lib64/libsvn_client-1.so.0 0x719b3af0 0x719be218 Yes /usr/lib64/libsvn_delta-1.so.0 0x717a9970 0x717ad198 Yes /usr/lib64/libsvn_fs-1.so.0 0x7159ce40 0x715a36e8 Yes /usr/lib64/libsvn_ra-1.so.0 0x7136e640 0x7138a5c8 Yes /usr/lib64/libsvn_repos-1.so.0 0x710cb930 0x7113f688 Yes /usr/lib64/libsvn_wc-1.so.0 0x70ea5c40 0x70eb2a48 Yes /usr/lib64/libsvn_diff-1.so.0 0x70bbc3e0 0x70c65be8 Yes /usr/lib64/libsvn_subr-1.so.0 0x70994ce0 0x7099a4d8 Yes /usr/lib64/libsvn_swig_perl-1.so.0 0x003acea02120 0x003acea0d3a8 Yes /lib64/libz.so.1 0x003bb9c091e0 0x003bb9c1c668 Yes /usr/lib64/libaprutil-1.so.0 0x003ad1603cd0 0x003ad161cc88 Yes /lib64/libexpat.so.1 0x003adc2286a0 0x003adc33e9d8 Yes /usr/lib64/libdb-4.7.so 0x003bba00b8f0 0x003bba023ab8 Yes /usr/lib64/libapr-1.so.0 0x70790b40 0x70791058 Yes /usr/lib64/libsvn_fs_util-1.so.0 0x003ad4a015a0 0x003ad4a02cc8 Yes /lib64/libuuid.so.1 0x7058ca30
Re: Problem with subversion-perl RPMs from WanDisco?
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 sti...@att.net writes: 0x7138af10 in ?? () (gdb) bt #0 0x7138af10 in ?? () #1 0x003bba01899e 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 0x003bba018975 in apr_pool_destroy (pool=0x7e1498) at memory/unix/apr_pools.c:779 #4 0x003bba018b84 in apr_pool_terminate () at memory/unix/apr_pools.c:605 #5 0x71e5153d in _wrap_apr_terminate (my_perl=value optimized out, cv=value optimized out) at core.c:2590 #6 0x003ae0aa6815 in Perl_pp_entersub (my_perl=0x603010) at pp_hot.c:2888 #7 0x003ae0aa4b06 in Perl_runops_standard (my_perl=0x603010) at run.c:40 #8 0x003ae0a4c5df in Perl_call_sv (my_perl=0x603010, sv=0x6c9190, flags=6) at perl.c:2721 #9 0x003ae0a4cb1d in Perl_call_list (my_perl=0x603010, oldscope=1, paramList=0x6c9388) at perl.c:5276 #10 0x003ae0a4e947 in perl_destruct (my_perl=0x603010) at perl.c:630 #11 0x00400e01 in main (argc=3, argv=0x7fffe5a8, env=0x7fffe5c8) 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?
On 9/12/14 11:54 AM, Branko Čibej wrote: On 12.09.2014 20:37, Philip Martin wrote: Philip Martin philip.mar...@wandisco.com writes: Alexey Neyman sti...@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?
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.
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: 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.
