Bug 177243 - subversion-javahl crashes eclipse in rawhide
subversion-javahl crashes eclipse in rawhide
Product: Fedora
Classification: Fedora
Component: subversion (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
Depends On:
  Show dependency treegraph
Reported: 2006-01-08 00:12 EST by Havoc Pennington
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-26 21:39:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
jvm crash (55.78 KB, text/plain)
2006-01-08 00:12 EST, Havoc Pennington
no flags Details

  None (edit)
Description Havoc Pennington 2006-01-08 00:12:46 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)
Comment 1 Havoc Pennington 2006-01-08 00:12:46 EST
Created attachment 122916 [details]
jvm crash
Comment 2 Joe Orton 2006-01-09 05:01:47 EST
Have you tried reporting this upstream (to either subclipse or Subversion I
Comment 3 Havoc Pennington 2006-01-11 20:58:44 EST
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...
Comment 4 Havoc Pennington 2006-02-26 20:26:42 EST
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

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
C  [libsvnjavahl-1.so.0.0.0+0xd243] 
C  [libsvnjavahl-1.so.0.0.0+0x2285e] 
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
v  ~StubRoutines::call_stub
V  [libjvm.so+0x174fec]
V  [libjvm.so+0x2821f8]
Comment 5 Havoc Pennington 2006-02-26 21:39:26 EST
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 

Note You need to log in before you can comment on or make changes to this bug.