With native lib prefs

[GrmpCerber]

Hi,
I had a problem with the built-in binaries so I've added two option to be able to force either the path or the whole JNI.

Hope this could be usefull to someone

regards

PS. this is a second attempt with a branch as ref instead of a tag as pull request source.
I changed the system.load call so that the path could be fully specified

[wg]

Hello, thank you for the pull request! This isn't quite the method I'd want to override the library loading behavior, but I've just pushed a commit that implements an alternative method and released it as 1.4.0.

With the latest commit you may set the system property com.lambdaworks.jni.loader to one of the following:

• jar - extract & load native library from jar as usual
• nil - don't load native library at all
• sys - use System.loadLibrary, which may require java.library.path to be set

[GrmpCerber]

Thanks will, I'll check that on monday.

regards

[GrmpCerber]

Hi Will
I "don't disagree" ;) with you but I was unsure on which method to use to load the library, so I've asked the question on security.stackexchange.com and other seems to think loadLibrary is not the most secure option.
What do you think about it ?

Regards

[wg]

Hi Thomas, I guess I don't agree that System.load is more secure than System.loadLibrary as both depend on a path that you must configure. In the case of System.loadLibrary that path is the system property java.library.path, which is a well known and standard path and is a useful place to consolidate all of the native libraries used by some application. Of course that location needs to be protected, but so would any custom path you stored libraries in.

[wg]

By the way, have you been able to track down the issue you're having with the automatic library extraction and loading? I would certainly like to fix any issues with that if possible! Having to set com.lambdaworks.jni.loader should only be necessary in exceptional cases, like running on a read-only filesystem, using some unusual CPU, etc.

[GrmpCerber]

Sorry Will, I forgot to explain you why I haven't raised a warning on bug itself.
In fact, using 1.3.3 built-in is crashing the JVM with a core dump on my servers.
Since they are custom made linux I've cloned the source and recompile everything myself and ... Tada ! it works so I guess it is just due to my custom made linux and you don't need to waste YOUR time searching for MY root cause.

[wg]

@GrmpCerber thank you for saving me the debugging time =) Definitely a shame that it doesn't work out of the box, the shared library should have pretty few dependencies. Unfortunately I haven't been able to give it much compatibility testing though.

[GrmpCerber]

From my last core dump, all I can say is that I'm definetly not an expert in debugging linux internals :)
If you have an idea, here are the most interesting parts (in my opinion) :

#  SIGFPE (0x8) at pc=0x00007f2ab877763e, pid=3745, tid=1098926416
#
# JRE version: 6.0_20-b02
# Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode linux-amd64 )
# Problematic frame:
# C  [ld-linux-x86-64.so.2+0x863e]

...

Stack: [0x0000000041704000,0x0000000041805000],  sp=0x0000000041801de0,  free space=3f70000000000000018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [ld-linux-x86-64.so.2+0x863e]
C  [ld-linux-x86-64.so.2+0x9fae]
C  [ld-linux-x86-64.so.2+0x10285]
C  [ld-linux-x86-64.so.2+0xc146]
C  [libdl.so.2+0x11aa]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  java.lang.ClassLoader$NativeLibrary.load(Ljava/lang/String;)V+0
j  java.lang.ClassLoader.loadLibrary0(Ljava/lang/Class;Ljava/io/File;)Z+300
j  java.lang.ClassLoader.loadLibrary(Ljava/lang/Class;Ljava/lang/String;Z)V+127
j  java.lang.Runtime.load0(Ljava/lang/Class;Ljava/lang/String;)V+57
j  java.lang.System.load(Ljava/lang/String;)V+7
j  com.lambdaworks.jni.JarLibraryLoader.load(Ljava/lang/String;Z)Z+98

From wikipedia :

SIGFPE
The SIGFPE signal is sent to a process when it executes an erroneous arithmetic operation, such as division by zero

Which means (from what I understand) that your compiled version is doing something like dividing by zero with my linux LD internals ... puzzeling
That's why I've dropped debugging and recompiled it.

[wg]

Weird! Out of curiosity, what CPU is running that box? Assume it's some standard amd64 processor?

[GrmpCerber]

In fact this core dump comes from a virtual machine under a xen hypervisor.
The virtual proc states to be : Intel(R) Xeon(R) CPU L5520 @ 2.27GHz

[GrmpCerber]

(of course flags indicate that it has both sse and sse2 )

[wg]

Curious, would you mind extracting the shared lib from the jar and doing an ldd on it?

[GrmpCerber]

Your "in-jar" 1.3.3 lib :

        linux-vdso.so.1 =>  (0x00007fff5dbff000)
        libc.so.6 => /lib64/libc.so.6 (0x00007ff000f66000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ff00149b000)

My recompiled version :

        linux-vdso.so.1 =>  (0x00007fffb3fff000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f23216e9000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f2321c1e000)

[wg]

No missing libraries at least... I'll have to try a couple of different distributions in a VM sometime, see what their behavior is. I'd hoped that the shared library was reasonably portable between Linux systems on the same arch at least. Pure Java performance is pretty terrible for any sort of server use =/

[GrmpCerber]

Yes I agree on perf : while testing, something whent wrong and, since you do not log exceptions raised by the loading process, I went on pure java impl without knowing it (See my new #13 ) ... prefs do s*cks in pure java (but, on the whole, I think you did a pretty good job)