On 22.10.2015 22:05, Philip Martin wrote:
> JavaHL uses JNI to load Subversion shared libraries and it includes a
> runtime version check to ensure that the loaded library is the right
> version.  A program built with 1.8 would report an error if it loaded
> 1.7 at runtime.  It seems we have introduced a binary incompatibility in
> 1.9 that causes the JVM to SEGV rather than report an error.
>
> A simple Java program:
>
> $ cat xx.java
> import org.apache.subversion.javahl.*;
> public class xx {
>   public static void main(String argv[]) {
>     System.out.println("hello");
>     ISVNRepos repos = new SVNRepos();
>   }
> };
>
> Build with 1.8 and run with 1.7:
>
> $ javac -g -extdirs /usr/local/subversion-1.8/lib/svn-javahl xx.java
> $ java -Djava.library.path=/usr/local/subversion-1.7/lib -cp 
> /usr/local/subversion-1.8/lib/svn-javahl/svn-javahl.jar:. xx
> hello
> Exception in thread "main" java.lang.LinkageError: Native library version 
> must be at least 1.8.0, but is only 1.7.23-dev (under development)
>       at 
> org.apache.subversion.javahl.NativeResources.init(NativeResources.java:136)
>       at 
> org.apache.subversion.javahl.NativeResources.loadNativeLibrary(NativeResources.java:99)
>       at org.apache.subversion.javahl.SVNRepos.<clinit>(SVNRepos.java:46)
>       at xx.main(xx.java:5)
>
> Build with 1.9 and run with 1.8:
>
> $ javac -g -extdirs /usr/local/subversion/lib/svn-javahl xx.java
> $ java -Djava.library.path=/usr/local/subversion-1.8/lib -cp 
> /usr/local/subversion/lib/svn-javahl/svn-javahl.jar:. xx
> hello
> Aborted
>
> The stack trace shows:
>
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> C  [libapr-1.so.0+0x27b54]  apr_threadkey_private_get+0x4

I removed JNIThreadData.h/.cpp in r1533804, that's where the
thread-private keys were used. The thread-specific data was no longer
needed, because in 1.9 we have a guaranteed single-threaded context for
initializing the native libraries.

But I don't think this can be the source of the issue ... looking ...

Ah, I think I have it ... I also removed

    private static native void initNativeLibrary();

which is called from NativeResources.init in 1.8 and isn't called at all
(of course) in 1.9. Oh sheesh.

I'll fix this; it's a trivial matter of resurrecting a deleted file and
making the function no-op.

-- Brane

Reply via email to