rzel / svnx

Automatically exported from code.google.com/p/svnx
0 stars 0 forks source link

Crash when starting in Mountain Lion #180

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Upgrade OS X to Mountain Lion
2. Disable Gatekeeper (due to missing developer certificate)
3. Try to run svnX

What is the expected output? What do you see instead?
svnX crashes.

What version of the product are you using? On what operating system?
svnX 1.3.3, OS X 10.8 Mountain Lion

Please provide any additional information below.

Dyld Error Message:
  Library not loaded: /usr/lib/libpq.5.dylib
  Referenced from: /opt/subversion/lib/libsvn_client-1.0.dylib
  Reason: no suitable image found.  Did find:
    /usr/lib/libpq.5.dylib: mach-o, but wrong architecture

So, svnX (i386, ppc) uses libsvn_client (i386, x86_64), which uses libpq 
(x86_64).

This looks like the upgrade to Mountain Lion removed i386 support for libpq. 
Could you provide x86_64 binaries for svnX? As far as I understand, this should 
solve the issue.

If you see another feasible soultion, I would ha happy to know.

Original issue reported on code.google.com by ag...@posteo.de on 27 Jul 2012 at 9:47

GoogleCodeExporter commented 9 years ago
I don’t have OS X 10.8.
Many people are/have been using svnX on OS X 10.8 successfully.
[I was led to believe that you can enable unsigned applications by simply 
right-clicking them & selecting ‘Open’.
 No need to disable Gatekreeper.]

According to Google libpq is part of PostgreSQL.  None of my copies of 
Subversion link against this,
so you must be using some 3rd party extension (or something).

The simple workaround for now would seem to be to disable the ‘Call 
Subversion libraries directly’ preference.
You can do this without launching svnX by entering the following in 
Terminal.app:
    defaults write com.lachoseinteractive.svnX useOldParsingMethod -bool YES

However, this will impact the performance of svnX as it will have to run the 
svn CLI and parse its output.
Alternatively you could try replacing your copy of libpq with the one from 
10.7.x
or you could try building your own or obtain a 32/64-bit version from somewhere 
else.
Or you could `lipo -remove i386` the libsvn_client as it’s broken without 
compatible dependencies.
(But this, too, will also disable ‘Call Subversion libraries directly’ 
implicitly.)

A future release of svnX will, most likely, include 64-bit support.
However, that is unlikely to be a 1.x release.

Original comment by chris...@gmail.com on 27 Jul 2012 at 3:18

GoogleCodeExporter commented 9 years ago
Thanks a lot for the quick reply and the hints. You can indeed right-click, 
select "open" and then confirm that you know what you do.

I use the svn 1.7.5 binaries from 
http://www.wandisco.com/subversion/download#osx since these seem to be the most 
recent ones that are freely available. I have no idea why they require libpq, 
since it should be vanilla Apache svn.

The workaround does not work - svnX still crashes rightaway with the same 
message. I verified the setting by calling efaults read 
com.lachoseinteractive.svnX useOldParsingMethod, which returned 1.

Removing i386 support from libsvn_client leads to another crash when running 
svnX:
Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000

I will just wait for wandisco to release a binary compiled against 10.8 and 
report here what happens. Maybe they provide a workaround themselves. In the 
meantime, I can just use the command line tools, since they run in 64bit mode, 
which still works. 

Original comment by ag...@posteo.de on 27 Jul 2012 at 7:44

GoogleCodeExporter commented 9 years ago
My mistake.
SvnX weak links against various Subversion libraries via symbolic links in its 
bundle.
If the libs/symbols are available it then tests the Subversion lib versions for 
compatibility.
However, its missing an explicit test for a libsvn_client symbol (instead 
assuming it must be valid if the others are).
Unfortunately, in this case, it appears to be the only invalid lib/symbol.

The workaround is simply to delete one of the symbolic links to one of the 
other libs:
    rm <path-to-your-svnX.app>/Contents/Frameworks/libapr.dylib
That will prevent it calling into any of Subversion’s libs & disable ‘Call 
Subversion libraries directly’.
[Of course you wouldn’t be able to do that had the application been signed. 
:-)]

I looked at the libsvn_client in Subversion-1.7.5_10.7.x.pkg from WANdisco 
(that they claim is a “vanilla” Subversion 1.7.5).
It does indeed link against libpq.
I have 1.7.4 that I built from source (from Apache’s repo).
It does NOT link against libpq.
There is NO reference to libpq anywhere in the source.
(Nor in the Subversion 1.7.5 makefile or configure script.)

So, hopefully, it should be easy for WANdisco to fix it (as it appears to be 
their problem).

Original comment by chris...@gmail.com on 28 Jul 2012 at 1:56

GoogleCodeExporter commented 9 years ago
After removing the symbolic link, it worked. For some reason I also had to 
delete the one to libsvn_client before svnX started, but that seems to be a 
feasible workaround for now.

Thanks again - especially for looking into the WANdisco package as well!

Original comment by ag...@posteo.de on 28 Jul 2012 at 8:53

GoogleCodeExporter commented 9 years ago
Unlinking libapr and libsvn_client fixed this issue for me. Thanks!

Original comment by kmark937 on 28 Jul 2012 at 9:51

GoogleCodeExporter commented 9 years ago
Today, WANdisco provided an updated build, which seems to work so far.
I am just not sure whether svnX attempts to use libsvn_client again.
So far I restored the symlinks I deleted and disabled the useOldParsingMethod.
Is there any way I can verify which method svnX actually uses?

Thanks,
Andreas

Original comment by ag...@posteo.de on 9 Aug 2012 at 5:58

GoogleCodeExporter commented 9 years ago
It’s probably easier/better to simply re-download svnX and restore it from 
the disc image then try to recreate the symlinks.

If you open svnX’s preferences dialog then the ‘Call Subversion libraries 
directly’ checkbox should be enabled (if it’s detected suitable libs) & 
checked (if it’s using them).
Also you should be able to toggle that checkbox between doing refreshes of a 
working copy window & notice a significant (~3 to 5 times) speed up when it is 
checked.  [Do several refreshes so as to prime the disc cache.]

Original comment by chris...@gmail.com on 9 Aug 2012 at 6:27

GoogleCodeExporter commented 9 years ago
Thanks for the support and the workarounds. 
Everything now works again with the new subversion build provided by WANdisco.
From my point of view, the issue can be closed.

Original comment by ag...@posteo.de on 9 Aug 2012 at 7:20

GoogleCodeExporter commented 9 years ago
Issue 183 has been merged into this issue.

Original comment by chris...@gmail.com on 27 Aug 2012 at 6:09

GoogleCodeExporter commented 9 years ago
For me the removal of the sym-links didn't solve the problem. I still get the 
same error message.

I have installed the subversion libraries from the macports repository.

Original comment by funsh...@gmail.com on 28 Aug 2012 at 4:42

GoogleCodeExporter commented 9 years ago
Fixed by installing updated Subversion libraries from WANdisco.

Original comment by chris...@gmail.com on 4 Sep 2012 at 5:14

GoogleCodeExporter commented 9 years ago
Issue 193 has been merged into this issue.

Original comment by chris...@gmail.com on 17 Jan 2013 at 12:41

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Issue 205 has been merged into this issue.

Original comment by chris...@gmail.com on 21 May 2014 at 12:53