Corrupted error messages on Linux

[skissane]

Error message in LastErrorException is corrupted on Linux. I think this is a reoccurrence/regression of issue #215. I am using jna-4.1.0.jar from Maven central, with Oracle JDK 1.7.0_71 64-bit, Fedora 21 x86 64-bit (kernel 3.17.7-300.fc21.x86_64), glibc-2.20-5.fc21.x86_64

Here is my sample code:

import com.sun.jna.LastErrorException;
import com.sun.jna.Library;
import com.sun.jna.Memory;
import com.sun.jna.Native;
import com.sun.jna.Pointer;

public final class JNABugTest {

   public static void main(String[] args) {
      INSTANCE.read(Integer.MAX_VALUE, new Memory(1024), 1024);
   }

   static POSIX INSTANCE = (POSIX) Native.loadLibrary(POSIX.class);

   interface POSIX extends Library {

      long read(int fildes, Pointer buf, long nbyte) throws LastErrorException;
   }
}

i.e. trying to read from a file descriptor that should not exist, we expect a bad file descriptor error.

On Mac OS X 10.9.5, I get the results I expect:
Exception in thread "main" com.sun.jna.LastErrorException: [9] Bad file descriptor

But on Linux the error message is corrupted:
Exception in thread "main" com.sun.jna.LastErrorException: [9] h

I think I know the problem. If I extract jna-4.1.0.jar into a working directory, then run the following:

$ nm com/sun/jna/linux-x86-64/libjnidispatch.so  | grep strerror
                 U strerror_r@@GLIBC_2.2.5

Note it is importing the GNU strerror_r, not the XSI strerror_r. The XSI strerror_r is not called strerror_r, it is called _xpg_strerror_r. I think if you used the XSI version instead, the problem would go away. Check output of:

nm /lib64/libc.so.6  | grep strerror_r

you can see the XSI version (__xpg_strerror_r) is exported separately.

[dblock]

Looks like a legit bug, Would appreciate a PR with a fix + test.

[twall]

IIRC this was forced by defining _XOPEN_SOURCE 600; perhaps this is no longer sufificient?

On Jan 29, 2015, at 7:17 PM, skissane [email protected] wrote:

Error message in LastErrorException is corrupted on Linux. I think this is a reoccurrence/regression of issue #215. I am using jna-4.1.0.jar from Maven central, with Oracle JDK 1.7.0_71 64-bit, Fedora 21 x86 64-bit (kernel 3.17.7-300.fc21.x86_64), glibc-2.20-5.fc21.x86_64

Here is my sample code:

import com.sun.jna.LastErrorException
;

import com.sun.jna.Library
;

import com.sun.jna.Memory
;

import com.sun.jna.Native
;

import com.sun.jna.Pointer
;

public final class JNABugTest
{

public static void main(String[] args
) {

INSTANCE.read(Integer.MAX_VALUE, new Memory(1024), 1024
);
}

static POSIX INSTANCE = (POSIX) Native.loadLibrary(POSIX.
class);

interface POSIX extends Library
{

long read(int fildes, Pointer buf, long nbyte) throws LastErrorException
;
}
}

i.e. trying to read from a file descriptor that should not exist, we expect a bad file descriptor error.

On Mac OS X 10.9.5, I get the results I expect:
Exception in thread "main" com.sun.jna.LastErrorException: [9] Bad file descriptor

But on Linux the error message is corrupted:
Exception in thread "main" com.sun.jna.LastErrorException: [9] h

I think I know the problem. If I extract jna-4.1.0.jar into a working directory, then run the following:

$ nm com/sun/jna/linux-x86-64/libjnidispatch.so | grep strerror
U strerror_r@@GLIBC_2.2.5

Note it is importing the GNU strerror_r, not the XSI strerror_r. The XSI strerror_r is not called strerror_r, it is called _xpg_strerror_r. I think if you used the XSI version instead, the problem would go away. Check output of:

nm /lib64/libc.so.6 | grep strerror_r

you can see the XSI version (__xpg_strerror_r) is exported separately.

—
Reply to this email directly or view it on GitHub.

[skissane]

Observations:

1. Clone GIT repository. At HEAD, the JAR in dist/jna.jar has the same bug.
2. Yet I rebuild natives (just by running ant) - build/jna.jar does not have the bug
3. Checkout v4.1.0 tag. Once again, dist/jna.jar has bug
4. Yet rebuilding natives it doesn't

So, it looks like this may be due to the build environment somehow. What glibc version was dist/jna.jar built with? I am using glibc 2.20.

[matthiasblaesing]

Closing - this is fixed by #669.