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* mod_perl-2.0.2-2.i386.rpm 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] jvm crash
Have you tried reporting this upstream (to either subclipse or Subversion I suppose)?
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. I have - 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 something. 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 apr_threadkey_private_create(). 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 created. I won't speculate on the correct fix, but hopefully if my diagnosis is right one of you guys can fix it trivially. Thanks, Havoc 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 C [libsvnjavahl-1.so.0.0.0+0xd243] _ZN15JNIStackElementC1EP7JNIEnv_PKcS3_P8_jobject+0x33 C [libsvnjavahl-1.so.0.0.0+0x2285e] Java_org_tigris_subversion_javahl_SVNClient_ctNative+0x5e j org.tigris.subversion.javahl.SVNClient.ctNative()J+0 j org.tigris.subversion.javahl.SVNClient.<init>()V+6 j org.tigris.subversion.javahl.SVNClientSynchronized.<init>()V+9 j org.tigris.subversion.svnclientadapter.javahl.JhlClientAdapter.isAvailable()Z+560 j org.tigris.subversion.svnclientadapter.javahl.JhlClientAdapterFactory.setup()V+0 j org.tigris.subversion.subclipse.core.SVNClientManager.startup(Lorg/eclipse/core/runtime/IProgressMonitor;)V+10 j org.tigris.subversion.subclipse.core.SVNProviderPlugin.start(Lorg/osgi/framework/BundleContext;)V+21j org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run()Ljava/lang/Object;+56 v ~StubRoutines::call_stub V [libjvm.so+0x174fec] V [libjvm.so+0x2821f8]
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 are not. Gory details in the thread at http://subclipse.tigris.org/servlets/ReadMsg?list=users&msgNo=5838