jnr-ffi fails LoadLibraryTest pp64el on ubuntu 14. about jnr-ffi

[ralphbellofatto]

an interesting thing we see in the above trace is:

Apache Maven 3.0.5
Maven home: /usr/share/maven
Java version: 1.7.0_75, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-openjdk-ppc64el/jre
Default locale: en_US, platform encoding: ISO-8859-1
OS name: "linux", version: "3.16.0-30-generic", arch: "ppc64", family: "unix"

We installed the openjdk off the utopic site with " sudo apt-get install openjdk-7-jdk".

I would appear that maven is identifying the "arch" as ppc64 rather than ppc64el. That might, or might not be an issue for this function.

the output of uname -a is:

[jnr-ffi]# uname -a
Linux tulgpu002 3.16.0-30-generic #40-Ubuntu SMP Mon Jan 12 22:07:11 UTC 2015 ppc64le ppc64le ppc64le GNU/Linux

[headius]

I also noticed that "execstack" error, which previously I've only seen when the JVM loads the incorrect version of a library (in the previous case it was loading Linux-x86 on Linux-ARM).

It's difficult for me to diagnose this without being able to run the build and tests myself. I would suggest the following:

• Look into the log files the test runs output. They'll have more specific errors. I'm guessing they'll be linkage problems.
• Do some step-debugging or println-debugging in the jnr-ffi/jffi loading process and see if you can figure out where it goes wrong.

You could be right; it may simply not be detecting the platform or endianness correctly.

[ralphbellofatto]

what was pasted above was the entire stdout/stderr output, was there another place i should be finding log files?

[headius]

Yes, look at the log output. There should be test results under target/surefire, I believe, which will show the full errors.

[ralphbellofatto]

found it and I see:

-------------------------------------------------------------------------------
Test set: jnr.ffi.LibraryLoaderTest
-------------------------------------------------------------------------------
Tests run: 7, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 0.413 sec <<< FAILURE!
mapperWithFuctionMapper(jnr.ffi.LibraryLoaderTest)  Time elapsed: 0.111 sec  <<< ERROR!
java.lang.UnsatisfiedLinkError: could not load FFI provider jnr.ffi.provider.jffi.Provider
    at jnr.ffi.provider.InvalidProvider$1.loadLibrary(InvalidProvider.java:30)
    at jnr.ffi.LibraryLoader.load(LibraryLoader.java:269)

Now i have a ralphbel@tulgpu002:~/jnr-ffi$ ls ./src/main/java/jnr/ffi/provider/jffi/platform/ppc64le/linux/TypeAliases.java, so there is someting more basic for it tracking down where it determines what it is going to load

[headius]

If you need more assistance investigating, post the full failure error using https://gist.github.com. Otherwise keep me posted :-)

[ralphbellofatto]

the complete log is here:
https://gist.github.com/ralphbellofatto/58d8894a4963297f9524

[headius]

Ok, another flag to pass to that JVM: [EDITED] -verbose:jni

It's definitely having problems loading the library, and seems to be picking up the big-endian version. You might have better luck poking at this locally by turning on or adding some logging or doing some step-debugging to see why it's finding the wrong library (if that is indeed the case).

[headius]

Edited my comment...the flag is -verbose:jni

[ralphbellofatto]

I instrumented this code:

        static FFIProvider getInstance() {
            String providerName = System.getProperty("jnr.ffi.provider");
            System.out.print("RB: providerName " + providerName + "\n");

spit out this:

RB: providerName = null

So, where does this property get set?

[ralphbellofatto]

Where do i add that flag on the mvn command line?

[headius]

I think you can pass it through to maven and its sub-JVMs with JAVA_OPTS env var.

I'm not sure about that line of code or why/whether it would be null.

I don't suppose there's a possibility to get shell access to a ppc64le machine, is there? It would help us collaborate.

[ralphbellofatto]

that was a red-herring:

i changed the instrumentation to:

            String providerName = System.getProperty("jnr.ffi.provider");
        System.out.print("RB: providerName " + providerName + "\n");
            if (providerName == null) {
                Package pkg = FFIProvider.class.getPackage();
                String pkgName = pkg != null && pkg.getName() != null ? pkg.getName() : "jnr.ffi.provider";
                providerName = pkgName + ".jffi.Provider";
        System.out.print("RB: providerName... " + providerName + "\n");
            }

            try {
                return (FFIProvider) Class.forName(providerName).newInstance();

            } catch (Throwable ex) {
                return newInvalidProvider("could not load FFI provider " + providerName, ex);
            }

and got the following telemetry:

Running jnr.ffi.LibraryLoaderTest
RB: providerName null
RB: providerName... jnr.ffi.provider.jffi.Provider
OpenJDK 64-Bit Server VM warning: You have loaded library /tmp/jffi182293879281362770.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
RB: LibraryLoader non-existent-library
RB: LibraryLoader non-existent-library
RB: LibraryLoader non-existent-library

I think i have to dig into the class.forName... function.

[headius]

Somewhere before this it will have selected the .so to become that tmp/jffi so.

[ralphbellofatto]

do you know off hand what code selected the .so file here and how it made the decision which one it needed to select?

Getting company externals access to a ppc64el machine is something i'm trying to push through our management.

That is going to take a bit of time. We have to first reconfigure the machines to be accessable from outside our firewall (something we are planning for this cluster, for other colaborations), but have not done yet.

And then there is the process of getting you and other collaborators approved for access to these machines.

We realize that since we are serious about the OpenPower initiative that we are going to have to be proactive about making the resources for the open source community to solve problems like this.

For now. you have me to work through.

[ralphbellofatto]

ok, this is interesting:

I traced the problem into NativeRuntime and instrumented the following code:

    public static NativeRuntime getInstance() {
    System.out.print("RB: NativeRuntime getInstance\n");
    System.out.print("RB: NativeRuntime SingletonHolder.INSTANCE " + SingletonHolder.INSTANCE.getClass().getName()+"\n");
        return SingletonHolder.INSTANCE;
    }

    private static final class SingletonHolder {
        public static final NativeRuntime INSTANCE = new NativeRuntime();
    }

    private NativeRuntime() {
        super(ByteOrder.nativeOrder(), buildTypeMap());
    System.out.print("RB: NativeRuntime\n");
        NativeType[] nativeAliases = buildNativeTypeAliases();
        EnumSet<TypeAlias> typeAliasSet = EnumSet.allOf(TypeAlias.class);
        aliases = new Type[typeAliasSet.size()];

        for (TypeAlias alias : typeAliasSet) {
            if (nativeAliases.length > alias.ordinal() && nativeAliases[alias.ordinal()] != NativeType.VOID) {
                aliases[alias.ordinal()] = findType(nativeAliases[alias.ordinal()]);
            } else {
                aliases[alias.ordinal()] = new BadType(alias.name());
            }
        }
    }

I also instrumented the code that called it.

        static FFIProvider getInstance() {
            String providerName = System.getProperty("jnr.ffi.provider");
        System.out.print("RB: providerName " + providerName + "\n");
            if (providerName == null) {
                Package pkg = FFIProvider.class.getPackage();
                String pkgName = pkg != null && pkg.getName() != null ? pkg.getName() : "jnr.ffi.provider";
                providerName = pkgName + ".jffi.Provider";
        System.out.print("RB: providerName... " + providerName + "\n");
            }

            try {
                return (FFIProvider) Class.forName(providerName).newInstance();

            } catch (Throwable ex) {
        System.out.print("RB: FFIProvider newInvalidProvider\n");
                return newInvalidProvider("could not load FFI provider " + providerName, ex);
            }

Here is the telemetry:

Running jnr.ffi.LibraryLoaderTest
RB: providerName null
RB: providerName... jnr.ffi.provider.jffi.Provider
RB: constructor Provider
RB: NativeRuntime getInstance
OpenJDK 64-Bit Server VM warning: You have loaded library /tmp/jffi7859286392559998149.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
RB: FFIProvider newInvalidProvider
Tests run: 7, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 0.362 sec <<< FAILURE!

It would appear that the attempt to access SingletonHolder.INSTANCE, throws an exception.

also there is no trace of the stdout in from this code:

    private NativeRuntime() {
        super(ByteOrder.nativeOrder(), buildTypeMap());
    System.out.print("RB: NativeRuntime\n");

that appears to imply that this static internalize is not getting called:

    private static final class SingletonHolder {
        public static final NativeRuntime INSTANCE = new NativeRuntime();
    }

I was under the impression that private static final stuff would be called prior to any other code being initialized.

Of course, that could also mean that the System.out is not initialized at this point either.

Is there a way to trace the code during the static init phases?

[headius]

Static final stuff will run when the class is first accessed. Any classes the static initializer(s) run will also run their static init, and so on. So if you're not getting past the new NativeRuntime() part this is likely failing further down in NativeRuntime's static initializer, and so on.

[ralphbellofatto]

From your description, the static function should be able do a print.

We don't see the output for the print in this instrumentation:

    private static final class SingletonHolder {
        public static final NativeRuntime INSTANCE = new NativeRuntime();
    }

    private NativeRuntime() {
        super(ByteOrder.nativeOrder(), buildTypeMap());
    System.out.print("RB: NativeRuntime\n");

which seems to imply something important, and maybe explains the exception when the access happens...

[ralphbellofatto]

seems to be dying in the AbstractRuntime constructor, investigating.

[ralphbellofatto]

I did this insturmentation:

    public AbstractRuntime(ByteOrder byteOrder, EnumMap<NativeType, Type> typeMap) {
        System.out.print("RB: AbstractRuntime\n");
        this.byteOrder = byteOrder;

        EnumSet<NativeType> nativeTypes = EnumSet.allOf(NativeType.class);
        System.out.print("RB: AbstractRuntime (1)\n");
        types = new Type[nativeTypes.size()];
        System.out.print("RB: AbstractRuntime (2)\n");
        for (NativeType t : nativeTypes) {
            types[t.ordinal()] = typeMap.containsKey(t) ? typeMap.get(t) : new BadType(t.toString());
        }
        System.out.print("RB: AbstractRuntime (3)\n");

this.addressSize = types[NativeType.ADDRESS.ordinal()].size();
        System.out.print("RB: AbstractRuntime (4)\n");
        this.longSize = types[NativeType.SLONG.ordinal()].size();
        System.out.print("RB: AbstractRuntime (5)\n");
        this.addressMask = addressSize == 4 ? 0xffffffffL : 0xffffffffffffffffL;
        System.out.print("RB: AbstractRuntime-\n");

}

And got

    Running jnr.ffi.LibraryLoaderTest
    RB: providerName null
    RB: providerName... jnr.ffi.provider.jffi.Provider
    RB: constructor Provider
    RB: NativeRuntime getInstance
    RB: AbstractRuntime
    RB: AbstractRuntime (1)
    RB: AbstractRuntime (2)
    RB: AbstractRuntime (3)
    OpenJDK 64-Bit Server VM warning: You have loaded library /tmp/jffi1226611104110361213.so which might have disabled stack guard. The VM will try to fix the stack guard now.
    It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.

so that says this statment is throw the exception.

this.addressSize = types[NativeType.ADDRESS.ordinal()].size();

I'm not seeing the "ordnal" function in the jnr-ffi code...

is this some basic Java function. I see that ADDRESS part of:

public enum NativeType {
 /** Native memory address.  Equivalent to a C void* or char* pointer type.  Can be either 4 or 8 bytes in size, depending on the platform. */
    ADDRESS
...

[ralphbellofatto]

Now i'm confused:

I traced the problem back into what fills out the types array in

    private static EnumMap<NativeType, Type> buildTypeMap() {
    System.out.print("RB: NativeRuntime::buildTypeMap\n");
        EnumMap<NativeType, Type> typeMap = new EnumMap<NativeType, Type>(NativeType.class);
        EnumSet<NativeType> nativeTypes = EnumSet.allOf(NativeType.class);

        for (NativeType t : nativeTypes) {
        System.out.print("RB: NativeRuntime::buildTypeMap \n");
            typeMap.put(t, jafflType(t));
        }

I instrumented the code TypeDelegate:

    private static final class TypeDelegate extends jnr.ffi.Type {
        private final com.kenai.jffi.Type type;
        private final NativeType nativeType;

        public TypeDelegate(com.kenai.jffi.Type type, NativeType nativeType) {
            this.type = type;
            this.nativeType = nativeType;

        System.out.print("RB: NativeRuntime TypeDelegate\n");
        System.out.print("RB: NativeRuntime TypeDelegate toString="+this.toString()+"\n");
        }

And it generated the following telemetry:

Running jnr.ffi.LibraryLoaderTest
RB: providerName null
RB: providerName... jnr.ffi.provider.jffi.Provider
RB: constructor Provider
RB: NativeRuntime getInstance
RB: NativeRuntime::buildTypeMap
RB: NativeRuntime::buildTypeMap
RB: NativeRuntime TypeDelegate
OpenJDK 64-Bit Server VM warning: You have loaded library /tmp/jffi1879761043680804233.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.

This appears to imply that this funciton throws an exception.

    private static final class TypeDelegate extends jnr.ffi.Type {
        private final com.kenai.jffi.Type type;
        private final NativeType nativeType;
...
        public String toString() {
            return type.toString();
        }

Did i just chase this problem back into another library the implementation for: com.kenai.jffi.Type?

If so, how do i go about debugging...?

[ralphbellofatto]

I'm not sure if this is significant or not, but I see this in the logs output:

Apache Maven 3.0.5
Maven home: /usr/share/maven
Java version: 1.7.0_75, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-openjdk-ppc64el/jre
Default locale: en_US, platform encoding: ISO-8859-1
OS name: "linux", version: "3.16.0-30-generic", arch: "ppc64", family: "unix"

[DEBUG] -----------------------------------------------------------------------
[DEBUG] Goal:          org.apache.maven.plugins:maven-antrun-plugin:1.1:run (default)
[DEBUG] Style:         Regular
[DEBUG] Configuration: <?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <artifacts>${plugin.artifacts}</artifacts>
  <project>${project}</project>
  <sourceRoot>${sourceRoot}</sourceRoot>
  <tasks>
    <exec dir="/gpfs/DDNgpfs1/ralphbel/jnr-ffi" executable="make" failonerror="true">
      <arg line="-f libtest/GNUmakefile"/>
      <arg line="BUILD_DIR=/gpfs/DDNgpfs1/ralphbel/jnr-ffi/target"/>
      <arg line="CPU=ppc64"/>
    </exec>${tasks}</tasks>
  <testSourceRoot>${testSourceRoot}</testSourceRoot>
</configuration>


[DEBUG] Setting system property [os.arch]=[ppc64]

And the system property os.arch is being picked up by the application and its supporting libraries at some point.

I pulled the source code from maven and found the line of code that prints:

OS name: "linux", version: "3.16.0-30-generic", arch: "ppc64", family: "unix"

That comes from the maven code in CLIReporting.java here:

    public static String showVersion()
    {
...
        version.append( "OS name: \"" ).append( Os.OS_NAME ).append( "\", version: \"" ).append( Os.OS_VERSION ).append(
            "\", arch: \"" ).append( Os.OS_ARCH ).append( "\", family: \"" ).append( Os.OS_FAMILY ).append( "\"" );
        return version.toString();
    }

That pulls the information from:

import org.codehaus.plexus.util.Os;

If i do the same in the jnr-jffi code we see:

        System.out.print("RB: Os.OS_ARCH="+Os.OS_ARCH+"\n");
which prints
        RB: Os.OS_ARCH=ppc64

This would indicate that at least part of the stuff maven relies on miss-reports the os architecture.

I have more of a concern about what is putting this system property information into the system.

[DEBUG] Setting system property [os.arch]=[ppc64]

As that is likely screwing something up as well.

[ralphbellofatto]

Yikes,

This comes all the way from the OpenJdk implementation:

I wrote a very simple java properties dumper.

class sysprop{
  public static void main(String[] args){
    System.getProperties().list(System.out);
   }
}

ran it and it and we get:

ralphbel@tulgpu002:~/java$ java sysprop |  grep arch
os.arch=ppc64
sun.arch.data.model=64

I figure that the system can't figure which of the jffi-1.2.8-native.jar classes to load, although i have not caught it in the act of doing that yet.

So now to figure out why this is not reporting the correct value and how to get it fixed...

[ralphbellofatto]

same issue happens with java8 as well as java8.

[headius]

Ok, so I guess what we need to do is add logic under the "ppc64" section to check the platform endianness, since OpenJDK appears to report "ppc64" regardless of endianness. I'll make that change and you can try it out.

You mentioned some deeper problems in the other PR...will you open another issue for those problems?

[ralphbellofatto]

that would be one way to try to fix that now.

However, that would only fix this modules attempt at finding the proper jar modules, and not others.

For ppcel support on openJDK, the openJDK distrubition from ubuntu needs to be fixed. It should be reporting the same value as uname -p, which on the ubuntu ppc64le system reports:

ralphbel@tulgpu002:~/jnr-ffi$ uname -p
ppc64le

The proper fix for this is to get the openJDK distro fixed.

[headius]

I have the power to file OpenJDK bugs...I will file one for this issue.

Meanwhile, it's certainly not wrong for us to detect LE in the ppc64 section and do the right thing with it.

[headius]

Filed: https://bugs.openjdk.java.net/browse/JDK-8075461

[ralphbellofatto]

no, it would not be "wrong" to try to correct this in this library, but this library will NOT be the only thing that blows up because the os.arch does not match the uname -p output.

[headius]

Oops, my bug was a duplicate. Here's a better one: https://bugs.openjdk.java.net/browse/JDK-8073139

[ralphbellofatto]

NOTE: this may not be an openJDK issue but an issue with how that openJDK gets into the ubuntu distro...

I took a look at the openJDK source files, and it would appear that the ARCh value is supposed to come from the uname -p command during the build of the binaries.

[headius]

If OpenJDK is not at fault then it could be that Ubuntu is cross-compiling the ppc64le binaries without compensating for uname, maybe?

[ralphbellofatto]

this bug: https://bugs.openjdk.java.net/browse/JDK-8073139 is interesting.

It appears to imply that there was a decision not to give the architecture a unique name.

Maybe my analysis that it came from uname -p in the openjdk makefiles is incorrect.

One thing about this which is interesting is that the IBM jdk reports the os.arch the same way that uname -p does.

so, can we find out from openJDK if the os.arch is working, as designed, or is there going to be a change to this..?

Or was this some distribution error.?

[ralphbellofatto]

I took a look at the proposed code change, and I was incorrect, this is not a distro error, but an error in how the openJDK was done.

It would be good to get some idea when this will be fixed, otherwise, a lot of java code is going to just break.

[headius]

@gnu-andrew has a webrev (patch) on that issue you could use to build your own OpenJDK with the correct arch...perhaps we could try that for now so we can progress to the next issue?

[ralphbellofatto]

we could work the problem on the ibm jdk i have installed on this system if you like? That would be a lot less work than figuring out how to build and patch the openJDK.

Or do you think sticking with the openJDK is the only path we should persue here?

[headius]

Oh sure, using IBM JDK is probably a fine way to go too!

FWIW, building OpenJDK is easy...once you clone it and run the "get_sources.sh" script (if I remember the name right), it's just ./configure and then make all.

[ralphbellofatto]

two potential things to tackle here.

Should I work off of the code I forked, where I inserted the Missing Type aliases, or the master branch...

should I make a pull request for the ppc64 changes, since only the ppc64le changes were made to the tree?

[ralphbellofatto]

Also, is there a better way for us to collaborate, than exchanging e-mail or bouncing messages through this issue?

[headius]

@ralphbellofatto Two suggestions:

1. I think we should probably walk away from this issue and start new ones for additional work. This one has gotten too long and it is now straying far away from problems loading the native lib. Rule of thumb: one bug in jnr-ffi, one issue in the tracker.
2. We might be able to interact better if you joined me on IRC in the #jnr channel on Freenode, or if you IM me ("headius" on most services).

[ralphbellofatto]

Added ticket: #36 to deal with
additional failures other than the "loadlibrary" failure due to open stack.

[headius]

I think this is fixed now.

[ralphbellofatto]

I just downloaded the test on a ppc64le system running ubuntu 14.10 and the summary test resutts show:

ralphbel@tulgb004:~/jnr-ffi$ mvn -X test
Apache Maven 3.0.5
Maven home: /usr/share/maven
Java version: 1.7.0_75, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-openjdk-ppc64el/jre
Default locale: en_US, platform encoding: ISO-8859-1
OS name: "linux", version: "3.16.0-30-generic", arch: "ppc64", family: "unix"

....
Tests run: 112, Failures: 0, Errors: 99, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 13.073s
[INFO] Finished at: Fri Apr 24 08:25:24 EDT 2015
[INFO] Final Memory: 25M/185M
[INFO] ------------------------------------------------------------------------

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running jnr.ffi.MemoryIOTest
OpenJDK 64-Bit Server VM warning: You have loaded library /tmp/jffi5231722226666959714.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.278 sec <<< FAILURE!
Running jnr.ffi.struct.EnumTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.038 sec <<< FAILURE!
Running jnr.ffi.struct.AlignmentTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.069 sec <<< FAILURE!
Running jnr.ffi.byref.IntByReferenceTest
Tests run: 4, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 0.082 sec <<< FAILURE!
Running jnr.ffi.struct.StructureTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.061 sec <<< FAILURE!
Running jnr.ffi.LibraryTest
Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.023 sec <<< FAILURE!
Running jnr.ffi.DelegateTest
Tests run: 18, Failures: 0, Errors: 18, Skipped: 0, Time elapsed: 0.321 sec <<< FAILURE!
Running jnr.ffi.mapper.AnnotatedMappedTypeTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.023 sec <<< FAILURE!
Running jnr.ffi.PointerTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.063 sec <<< FAILURE!
Running jnr.ffi.byref.AddressByReferenceTest
Tests run: 4, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 0.07 sec <<< FAILURE!
Running jnr.ffi.ArrayTest
Tests run: 8, Failures: 0, Errors: 8, Skipped: 0, Time elapsed: 0.123 sec <<< FAILURE!
Running jnr.ffi.TypeDefinitionTest
Tests run: 3, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.06 sec <<< FAILURE!
Running jnr.ffi.StringArrayTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.022 sec <<< FAILURE!
Running jnr.ffi.byref.PointerByReferenceTest
Tests run: 4, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 0.119 sec <<< FAILURE!
Running jnr.ffi.struct.ArrayTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.022 sec <<< FAILURE!
Running jnr.ffi.byref.ByteByReferenceTest
Tests run: 4, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 0.069 sec <<< FAILURE!
Running jnr.ffi.BufferTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.028 sec <<< FAILURE!
Running jnr.ffi.mapper.CachingTypeMapperTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.051 sec
Running jnr.ffi.struct.UTF8StringFieldTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.02 sec <<< FAILURE!
Running jnr.ffi.StringTest
Tests run: 7, Failures: 0, Errors: 7, Skipped: 0, Time elapsed: 0.099 sec <<< FAILURE!
Running jnr.ffi.EnumTest
Tests run: 4, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 0.118 sec <<< FAILURE!
Running jnr.ffi.LastErrorTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.022 sec <<< FAILURE!
Running jnr.ffi.struct.UnionTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.021 sec <<< FAILURE!
Running jnr.ffi.ResultConverterTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.025 sec <<< FAILURE!
Running jnr.ffi.ObjectReferenceManagerTest
Tests run: 4, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 0.059 sec <<< FAILURE!
Running jnr.ffi.struct.PaddingTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.025 sec <<< FAILURE!
Running jnr.ffi.NumberTest
Tests run: 16, Failures: 0, Errors: 15, Skipped: 0, Time elapsed: 0.256 sec <<< FAILURE!
Running jnr.ffi.InvocationTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.021 sec <<< FAILURE!
Running jnr.ffi.struct.StructLayoutTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.02 sec <<< FAILURE!
Running jnr.ffi.GlobalVariableTest
Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.048 sec <<< FAILURE!
Running jnr.ffi.struct.AsciiStringFieldTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.024 sec <<< FAILURE!
Running jnr.ffi.LibraryLoaderTest
Tests run: 7, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 0.095 sec <<< FAILURE!