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