smartsvn 8.5.1 crashes under opensuse 13.1 x86_64 linux

MadPenguin
MadPenguin
like all previous 8.5.x versions, the new version 8.5.1 crashes on opensuse 13.1 x86_64 linux with:    libssl.so: undefined symbol: EVP_idea_cbc      But i found a workaround:  the new version creates a directory named "8.5" inside the ".smartsvn" directory like all the previous versions did with their version name. inside a new directory called "svn-tmp" was created, and there a directory called "2144" was created, where a lot of libraries are placed.  one of the libraries inside the "2144" directory is the libssl.so which crashed like it did with version 8.5 Release Candidate 2 and all 8.5 versions before.  i replaced the libssl.so by the libssl.so from my system from /usr/lib64.  after this it started.  and i also noticed that inside this "2144" directory the same libraries were stored under different names, instead of linking.  i cleaned this mess up with a proper "ldconfig" call.  but strangely enough i noticed that when restarting smartsvn the content of ~/.smartsvn/8.5/svn-tmp/2144 was again replaced by smartsvn with it's own versions.  it seems, that smartsvn checks at every start, if the files it wants to copy to ~/.smartsvn/8.5/svn-tmp/2144 are alle there and stored under a certain name.  so i replaced the wrong libssl.so, made the links to point to the correct names and made the ~/.smartsvn/8.5/svn-tmp/2144 read-only, and now it seems to work.    hard work to workaround your bug!    so, there are many things wrong with this new version under linux!    
     
  1. it's not a goog idea to supply an application with it's own version of libraries, when these libraries are already installed on the system.  
  2. if it's not possible to avoid point 1, then the supplied libraries should not crash.  
  3. the supplied libraries should not be installed two or three times under different names, but instead use linking.  

Last updated

MadPenguin
MadPenguin
smartsvn 8.5.2 and 8.5.3 crash as well!  what the hell is going on?
orbrey
orbrey
Not sure what's going on here at all to be honest. I've done a vanilla install of SUSE 13.1 in a VM and am trying to replicate the behaviour but it's working fine opening existing repositories - if that's still what you're trying to do when you get the crash error?  Is there anything else on the system that could be causing this? What version of java is it you're using, and how big is the repository? Does it contain a particularly large number of files?
MadPenguin
MadPenguin
orbrey;168440Not sure what's going on here at all to be honest. I've done a vanilla install of SUSE 13.1 in a VM and am trying to replicate the behaviour but it's working fine opening existing repositories - if that's still what you're trying to do when you get the crash error?[/QUOTE]    it crashes, when selecting any project to load.    [QUOTE=orbrey;168440]  Is there anything else on the system that could be causing this? What version of java is it you're using, and how big is the repository? Does it contain a particularly large number of files?
   of course i updated my system with all security updates.  did you update your 13.1 in the VM also?  i use java 1.8.0_05.    i don't think it has something to do with the repositoreis used.    as already said, it works, when i replace the libssl.so library file which smartsvn places in ~/.smartsvn/8.5/svn-tmp/2182 with the libssl.so library file from my system, which is stored in /lib64/libssl.so.1.0.0.    the libssl.so library file which is included in smartsvn seems not to be compatible with my system.  it is like there:  http://fixunix.com/mandriva/323373-stumped-symbol-loockup-error-undefined-symbol-evp_idea_cbc.html    i don't understand, why smartsvn installes 22 library files which are already in my system.  but, ok, that's the way it is done.    anyhow, i found out, that the libssl.so smartsvn provides does contain the symbol EVP_idea_cbc whereas the version from opensuse update does not contain it, and therefor doesn't crash.    the libssl.so from opensuse is from package libopenssl1_0_0-1.0.1g-11.40.1.x86_64 which is version 1.0.1g.    and as i tested it again today i found out that it works when started again.  this is strange.    after the update to smartsvn 8.5.3 a new directory ~/.smartsvn/8.5/svn-tmp/2182 is created, where all the 22 libraries are placed (in a very place consuming way, because it does not use links, but each file is placed 3 times using different names!) and then smartsvn starts, but when i select one of my projects to load, it crashes with the error "libssl.so: undefined symbol: EVP_idea_cbc".  when i start smartsvn after this again, it works.  and i can reproduce this.  when i delete the folder ~/.smartsvn/8.5/svn-tmp/2182 and start smartsvn again, it crashes again.  when i restart it after this, it works.  this was not the case with the previous 8.5.x versions.
orbrey
orbrey
Fully updated, yes, using xfce as desktop, jdk 1.8.0_5 - no problems checking out or opening existing repositories. I do see what you mean about the 2182 folder with all the lib files, I'll ask the dev team about that and get back to you.
MadPenguin
MadPenguin
orbrey;168460Fully updated, yes, using xfce as desktop, jdk 1.8.0_5 - no problems checking out or opening existing repositories. I do see what you mean about the 2182 folder with all the lib files, I'll ask the dev team about that and get back to you.
  ok, thanks.  it would be best, if smartsvn does not bring all the lib files, but uses the lib files from system. but if it has to use own lib files, they should work (which the libssl.so does not in my case), and it should not place the same lib file 3 times under differnet names.  this is how the 2182 folder should look like:   dr-xr-xr-x 3 rainer users 4096 13. Mai 09:38 . dr-xr-xr-x 3 rainer users 4096 13. Mai 17:21 .. -r--r--r-- 1 rainer users 197320 9. Apr 13:48 libapr-1.so lrwxrwxrwx 1 rainer users 11 9. Apr 13:53 libapr-1.so.0 -> libapr-1.so lrwxrwxrwx 1 rainer users 15 9. Apr 14:44 libapr-1.so.0.5.0 -> libaprutil-1.so -r--r--r-- 1 rainer users 145544 9. Apr 13:48 libaprutil-1.so lrwxrwxrwx 1 rainer users 15 9. Apr 13:55 libaprutil-1.so.0 -> libaprutil-1.so lrwxrwxrwx 1 rainer users 15 9. Apr 14:45 libaprutil-1.so.0.5.3 -> libaprutil-1.so -r--r--r-- 1 rainer users 1864416 22. Apr 11:33 libcrypto.so lrwxrwxrwx 1 rainer users 12 9. Apr 13:55 libcrypto.so.1.0.0 -> libcrypto.so -r--r--r-- 1 rainer users 139536 9. Apr 13:48 libexpat.so lrwxrwxrwx 1 rainer users 11 9. Apr 13:55 libexpat.so.0 -> libexpat.so lrwxrwxrwx 1 rainer users 11 9. Apr 14:45 libexpat.so.0.5.0 -> libexpat.so -r--r--r-- 1 rainer users 108416 9. Apr 13:48 libmagic.so lrwxrwxrwx 1 rainer users 11 9. Apr 13:55 libmagic.so.1 -> libmagic.so lrwxrwxrwx 1 rainer users 11 9. Apr 14:46 libmagic.so.1.0.0 -> libmagic.so -r--r--r-- 1 rainer users 108032 9. Apr 13:48 libsasl2.so lrwxrwxrwx 1 rainer users 11 9. Apr 13:55 libsasl2.so.3 -> libsasl2.so lrwxrwxrwx 1 rainer users 11 9. Apr 14:46 libsasl2.so.3.0.0 -> libsasl2.so -r--r--r-- 1 rainer users 101392 22. Apr 11:33 libserf-1.so lrwxrwxrwx 1 rainer users 12 9. Apr 13:55 libserf-1.so.1 -> libserf-1.so lrwxrwxrwx 1 rainer users 12 9. Apr 14:47 libserf-1.so.1.3.0 -> libserf-1.so -r--r--r-- 1 rainer users 415752 9. Apr 15:09 libssl.so lrwxrwxrwx 1 rainer users 9 9. Apr 13:55 libssl.so.1.0.0 -> libssl.so -r--r--r-- 1 rainer users 395416 9. Apr 13:48 libsvn_client-1.so lrwxrwxrwx 1 rainer users 18 9. Apr 13:55 libsvn_client-1.so.0 -> libsvn_client-1.so lrwxrwxrwx 1 rainer users 18 9. Apr 14:47 libsvn_client-1.so.0.0.0 -> libsvn_client-1.so -r--r--r-- 1 rainer users 70368 9. Apr 13:48 libsvn_delta-1.so lrwxrwxrwx 1 rainer users 17 9. Apr 13:55 libsvn_delta-1.so.0 -> libsvn_delta-1.so lrwxrwxrwx 1 rainer users 17 9. Apr 14:48 libsvn_delta-1.so.0.0.0 -> libsvn_delta-1.so -r--r--r-- 1 rainer users 78816 9. Apr 13:48 libsvn_diff-1.so lrwxrwxrwx 1 rainer users 16 9. Apr 13:55 libsvn_diff-1.so.0 -> libsvn_diff-1.so lrwxrwxrwx 1 rainer users 16 9. Apr 14:48 libsvn_diff-1.so.0.0.0 -> libsvn_diff-1.so -r--r--r-- 1 rainer users 37848 9. Apr 13:48 libsvn_fs-1.so lrwxrwxrwx 1 rainer users 14 9. Apr 13:55 libsvn_fs-1.so.0 -> libsvn_fs-1.so lrwxrwxrwx 1 rainer users 14 9. Apr 14:49 libsvn_fs-1.so.0.0.0 -> libsvn_fs-1.so -r--r--r-- 1 rainer users 211064 9. Apr 13:48 libsvn_fs_fs-1.so lrwxrwxrwx 1 rainer users 17 9. Apr 13:55 libsvn_fs_fs-1.so.0 -> libsvn_fs_fs-1.so lrwxrwxrwx 1 rainer users 17 9. Apr 14:49 libsvn_fs_fs-1.so.0.0.0 -> libsvn_fs_fs-1.so -r--r--r-- 1 rainer users 7128 9. Apr 13:48 libsvn_fs_util-1.so lrwxrwxrwx 1 rainer users 19 9. Apr 13:55 libsvn_fs_util-1.so.0 -> libsvn_fs_util-1.so lrwxrwxrwx 1 rainer users 19 9. Apr 14:50 libsvn_fs_util-1.so.0.0.0 -> libsvn_fs_util-1.so -r--r--r-- 1 rainer users 568216 22. Apr 11:36 libsvnjavahl-1.so lrwxrwxrwx 1 rainer users 17 9. Apr 13:55 libsvnjavahl-1.so.0 -> libsvnjavahl-1.so lrwxrwxrwx 1 rainer users 17 9. Apr 15:04 libsvnjavahl-1.so.0.0.0 -> libsvnjavahl-1.so -r--r--r-- 1 rainer users 53704 9. Apr 13:48 libsvn_ra-1.so lrwxrwxrwx 1 rainer users 14 9. Apr 13:55 libsvn_ra-1.so.0 -> libsvn_ra-1.so lrwxrwxrwx 1 rainer users 14 9. Apr 14:51 libsvn_ra-1.so.0.0.0 -> libsvn_ra-1.so -r--r--r-- 1 rainer users 34488 9. Apr 13:48 libsvn_ra_local-1.so lrwxrwxrwx 1 rainer users 20 9. Apr 13:55 libsvn_ra_local-1.so.0 -> libsvn_ra_local-1.so lrwxrwxrwx 1 rainer users 20 9. Apr 15:01 libsvn_ra_local-1.so.0.0.0 -> libsvn_ra_local-1.so -r--r--r-- 1 rainer users 178776 9. Apr 13:48 libsvn_ra_serf-1.so lrwxrwxrwx 1 rainer users 19 9. Apr 13:55 libsvn_ra_serf-1.so.0 -> libsvn_ra_serf-1.so lrwxrwxrwx 1 rainer users 19 9. Apr 15:02 libsvn_ra_serf-1.so.0.0.0 -> libsvn_ra_serf-1.so -r--r--r-- 1 rainer users 121160 9. Apr 13:48 libsvn_ra_svn-1.so lrwxrwxrwx 1 rainer users 18 9. Apr 13:55 libsvn_ra_svn-1.so.0 -> libsvn_ra_svn-1.so lrwxrwxrwx 1 rainer users 18 9. Apr 15:02 libsvn_ra_svn-1.so.0.0.0 -> libsvn_ra_svn-1.so -r--r--r-- 1 rainer users 207376 9. Apr 13:48 libsvn_repos-1.so lrwxrwxrwx 1 rainer users 17 9. Apr 13:55 libsvn_repos-1.so.0 -> libsvn_repos-1.so lrwxrwxrwx 1 rainer users 17 9. Apr 15:03 libsvn_repos-1.so.0.0.0 -> libsvn_repos-1.so -r--r--r-- 1 rainer users 982776 22. Apr 11:36 libsvn_subr-1.so lrwxrwxrwx 1 rainer users 16 9. Apr 13:55 libsvn_subr-1.so.0 -> libsvn_subr-1.so lrwxrwxrwx 1 rainer users 16 9. Apr 15:03 libsvn_subr-1.so.0.0.0 -> libsvn_subr-1.so -r--r--r-- 1 rainer users 683464 9. Apr 13:48 libsvn_wc-1.so lrwxrwxrwx 1 rainer users 14 9. Apr 13:55 libsvn_wc-1.so.0 -> libsvn_wc-1.so lrwxrwxrwx 1 rainer users 14 9. Apr 15:03 libsvn_wc-1.so.0.0.0 -> libsvn_wc-1.so lrwxrwxrwx 1 rainer users 12 13. Mai 09:36 libxml2.so -> libxml2.so.2 lrwxrwxrwx 1 rainer users 16 13. Mai 09:36 libxml2.so.2 -> libxml2.so.2.9.1 -r--r--r-- 1 rainer users 1356136 13. Mai 09:32 libxml2.so.2.9.1 -r--r--r-- 1 rainer users 90096 9. Apr 13:48 libz.so lrwxrwxrwx 1 rainer users 7 9. Apr 13:55 libz.so.1 -> libz.so lrwxrwxrwx 1 rainer users 7 9. Apr 15:04 libz.so.1.2.8 -> libz.so -r--r--r-- 1 rainer users 232 9. Apr 13:48 loadorder.txt dr-xr-xr-x 2 rainer users 4096 9. Apr 15:08 sasl2  /home/rainer/.smartsvn/8.5/svn-tmp/2182/sasl2: insgesamt 304 dr-xr-xr-x 2 rainer users 4096 9. Apr 15:08 . dr-xr-xr-x 3 rainer users 4096 13. Mai 09:38 .. -r--r--r-- 1 rainer users 15712 9. Apr 13:48 libanonymous.so lrwxrwxrwx 1 rainer users 15 9. Apr 13:56 libanonymous.so.3 -> libanonymous.so lrwxrwxrwx 1 rainer users 15 9. Apr 15:05 libanonymous.so.3.0.0 -> libanonymous.so -r--r--r-- 1 rainer users 18368 9. Apr 13:48 libcrammd5.so lrwxrwxrwx 1 rainer users 13 9. Apr 13:56 libcrammd5.so.3 -> libcrammd5.so lrwxrwxrwx 1 rainer users 13 9. Apr 15:06 libcrammd5.so.3.0.0 -> libcrammd5.so -r--r--r-- 1 rainer users 51264 9. Apr 13:48 libdigestmd5.so lrwxrwxrwx 1 rainer users 15 9. Apr 13:56 libdigestmd5.so.3 -> libdigestmd5.so lrwxrwxrwx 1 rainer users 15 9. Apr 15:06 libdigestmd5.so.3.0.0 -> libdigestmd5.so -r--r--r-- 1 rainer users 16384 9. Apr 13:48 liblogin.so lrwxrwxrwx 1 rainer users 11 9. Apr 13:56 liblogin.so.3 -> liblogin.so lrwxrwxrwx 1 rainer users 11 9. Apr 15:06 liblogin.so.3.0.0 -> liblogin.so -r--r--r-- 1 rainer users 32672 22. Apr 11:37 libntlm.so lrwxrwxrwx 1 rainer users 10 9. Apr 13:56 libntlm.so.3 -> libntlm.so lrwxrwxrwx 1 rainer users 10 9. Apr 15:07 libntlm.so.3.0.0 -> libntlm.so -r--r--r-- 1 rainer users 103032 9. Apr 13:48 libotp.so lrwxrwxrwx 1 rainer users 9 9. Apr 13:56 libotp.so.3 -> libotp.so lrwxrwxrwx 1 rainer users 9 9. Apr 15:07 libotp.so.3.0.0 -> libotp.so -r--r--r-- 1 rainer users 16576 9. Apr 13:48 libplain.so lrwxrwxrwx 1 rainer users 11 9. Apr 13:56 libplain.so.3 -> libplain.so lrwxrwxrwx 1 rainer users 11 9. Apr 15:08 libplain.so.3.0.0 -> libplain.so -r--r--r-- 1 rainer users 34560 9. Apr 13:48 libscram.so lrwxrwxrwx 1 rainer users 11 9. Apr 13:56 libscram.so.3 -> libscram.so lrwxrwxrwx 1 rainer users 11 9. Apr 15:08 libscram.so.3.0.0 -> libscram.so 
orbrey
orbrey
Hi,  Just asked about this.  Basically, including the libraries (most of them are svn binaries, due to the move to JavaHL for the SmartSVN back end) means that we can have one version of SmartSVN that'll work on any linux distribution. It also means that users can have two different versions of SmartSVN running in parallel, useful for testing a release candidate for example whilst still being able to have the stable version installed in case there's any issues. If SmartSVN installed dependencies to the system folders instead of them being bundled neither of those things would be possible (or at least a lot harder to do).  It's on the radar but this seems to be a fairly edge case scenario - we've only seen one other complaint about it as yet :/
MadPenguin
MadPenguin
orbrey;168462  Basically, including the libraries (most of them are svn binaries, due to the move to JavaHL for the SmartSVN back end) means that we can have one version of SmartSVN that'll work on any linux distribution. It also means that users can have two different versions of SmartSVN running in parallel, useful for testing a release candidate for example whilst still being able to have the stable version installed in case there's any issues. If SmartSVN installed dependencies to the system folders instead of them being bundled neither of those things would be possible (or at least a lot harder to do).  [/QUOTE]    ok, thats understandable.    [QUOTE=orbrey;168462]  It's on the radar but this seems to be a fairly edge case scenario - we've only seen one other complaint about it as yet :/
   ok, but please use links inside the 2182 folder in the future.
orbrey
orbrey
Apologies if I'm missing something here, but if we were linking to binaries installed in the system folders we're back to the issues I mentioned - we'd have to ensure they were installed in the system folders (so back to dependencies), which would mean separate installers for different linux distributions and not being able to run two versions in parallel.
MadPenguin
MadPenguin
orbrey;168464Apologies if I'm missing something here, but if we were linking to binaries installed in the system folders we're back to the issues I mentioned - we'd have to ensure they were installed in the system folders (so back to dependencies), which would mean separate installers for different linux distributions and not being able to run two versions in parallel.
   you misunderstood me.    i was talking about linking the libs which smartsvn places in the 2182 folder.    look in the 2182 folder in your installation.    it will look like this:    -rw-r--r-- 1 you users 197320 9. Apr 13:48 libapr-1.so  -rw-r--r-- 1 you users 197320 9. Apr 13:53 libapr-1.so.0  -rw-r--r-- 1 you users 197320 9. Apr 14:44 libapr-1.so.0.5.0      so the library libapr.so is placed 3 times in the 2182 folder under different namens.  this is nonsense.    it should look like this:    -rw-r--r-- 1 you users 197320 9. Apr 13:48 libapr-1.so  lrwxrwxrwx 1 you users 11 9. Apr 13:53 libapr-1.so.0 -> libapr-1.so  lrwxrwxrwx 1 you users 15 9. Apr 14:44 libapr-1.so.0.5.0 -> libaprutil-1.so      so the lib is only placed once in the 2182 folder and the other two names for it are implemented as links to it.  this saves disk-space and makes it easier to replace one of the libs, if needed, like in my case.
orbrey
orbrey
Unfortunately because we use java for the packing/unpacking of the archives, and java doesn't handle symlinks particularly well (especially where archives are concerned) that's not really possible, which is why they're all packaged as they are. As previously though the developers are aware of the situation.

1-11 of 11

Reply to this discussion

You cannot edit posts or make replies: You should be logged in before you can post.