Red Hat Bugzilla – Bug 177243
subversion-javahl crashes eclipse in rawhide
Last modified: 2007-11-30 17:11:20 EST
This is going to be sort of a nightmare to debug I think, unless it happens in
more situations than just this one...
I have Eclipse subversion support set up to use subversion-javahl
instead of the pure java Subclipse stuff, since it works better esp.
with ssh. This is done by passing
"-vmargs -Djava.library.path=/usr/lib" to eclipse so subversion-javahl gets found.
If I do this with rawhide then Eclipse crashes on startup.
I can fix it like so:
rpm -Uvh --oldpackage apr*0.9* httpd-2.0.54-16.i386.rpm subversion-*1.2.3*
Then Eclipse works. The mod_perl, httpd, etc. are just required to downgrade apr
and subversion again.
The backtrace is in subversion-javahl someplace, no real symbols. I'll attach
the backtrace that the sun jdk writes out (this is jdk-1.5.0_04-fcs).
jdk release 6 has the same issue (the first thing I tried was downgrading that,
but didn't matter)
Created attachment 122916 [details]
Have you tried reporting this upstream (to either subclipse or Subversion I
I haven't, I'm not sure honestly if it's subversion, subversion-javahl, or APR
that's the problem, or it could even be a bug in the beehive builds (weird build
root issues are hardly unheard of). I think it's at least technically not a
subclipse bug since in theory you shouldn't be able to segfault from pure java,
though subclipse could be passing in weird args or something I suppose.
I might suggest just leaving the bug for a bit and see if anyone else reports
issues or it goes away with newer versions...
I finally debugged this, and I believe it's a subclipse bug. I posted the
following to their user mailing list so we'll see if they agree.
- subclipse 0.9.37
- Sun jdk1.5.0_06
- subversion-javahl-1.3.0-4.2 from Fedora Core rawhide.
I'm appending a crash backtrace. Summary is that javahl crashes in
native code after JhlClientAdapter.isAvailable() calls new SVNClient().
I debugged it a bit and it looks like a Subclipse issue, though it seems
like a lot of people would be seeing this so I might be missing
I rebuilt the javahl native libs with some logging/assertions, and I
believe the problem is that the global initialization function for
javahl has not been called when the SVNClient is constructed in
isAvailable(). If you look at
org/tigris/subversion/javahl/NativeResources.java in javahl, when the
native lib is loaded javahl calls SVNClient.initNative(). subclipse
isAvailable() does native lib loading while skipping this step.
initNative() eventually calls JNIUtil::JNIGlobalInit() in javahl, which
in turn initializes the thread-local storage with
JNIThreadData::initThreadData(), which calls
If initNative() is skipped as it is in JhlClientAdapter.isAvailable(),
then you would expect a crash like this one in
apr_threadkey_private_get() since the thread private stuff isn't
I won't speculate on the correct fix, but hopefully if my diagnosis is
right one of you guys can fix it trivially.
C [libapr-1.so.0+0x1f585] apr_threadkey_private_get+0x15
C [libsvnjavahl-1.so.0.0.0+0xd718] _ZN13JNIThreadData17pushNewThreadDataEv+0x38
C [libsvnjavahl-1.so.0.0.0+0xdd87] _ZN7JNIUtil6setEnvEP7JNIEnv_+0x17
C [libsvnjavahl-1.so.0.0.0+0xde21] _ZN7JNIUtil7JNIInitEP7JNIEnv_+0x51
OK, all resolved. The basic deal is that subversion-javahl native lib broke
binary compatibility (it now requires that you call an init function), older
versions of Subclipse do not call the init function, so eclipse goes boom.
subclipse 0.9.107 is compatible with subversion-javahl 1.3.0 but older versions
Gory details in the thread at