On Fri, Jun 5, 2009 at 3:21 PM, Timothy Wall <twal...@dev.java.net> wrote:

On Jun 5, 2009, at 4:54 PM, Mark Click wrote:

At any rate, I doubt that's the issue. Looking at the stack trace, readObject is apparently pulling in some bogus data (does the library have a backing db or file-based preferences/settings?).

Indeed, the library has a large number of data files it uses. It appears to be crashing just after loading some Hidden Markov Model data files, which do exist in the filesystem and came straight from the library installer. Notably, those files are successfully loaded by the same call from the C demo, so I'm not sure in what other way they could be bogus.

Unless it's not loading the same files when run under a VM. Try dumping the environment variables for both setups (use getenv, not the shell's dump).

We tried that and all the environment variables are present and have correct values.

- Mark

On Fri, Jun 5, 2009 at 11:31 AM, Timothy Wall <twal...@dev.java.net> wrote: Rewrite your C test program to dynamically load the 3rd party library and its entry point (using dlopen/dlsym), then call it via function pointer.

If that doesn't provide any additional information, determine what other environmental differences there are between the VM-initiated call and the C-initiated call (I can't think of any at the moment, other than CPU and memory usage).

On Jun 5, 2009, at 2:11 PM, Mark Click wrote:

On Fri, Jun 5, 2009 at 4:12 AM, Timothy Wall <twal...@dev.java.net> wrote:

On Jun 4, 2009, at 11:50 PM, Mark Click wrote:

Timothy, thanks for the thoughtful response! Let me address each point:

According to Native.isProtected(), I'm not in protected mode.

You should probably do the libjsig setup anyway, since it appears your native code is using signals, which can interfere with the JVM's use of signals.

Good idea! But I tried that and no improvement, unfortunately.

It sure does look like it's dereferencing a null pointer, but like I said the exact same library works fine when called from C with the same parameters. Your suggestion about LD_LIBRARY_PATH is a good one, but the var looks correct whenever I check it, and the libraries only exist in one directory. I agree it's probably not a mapping problem, but the C version is:

SWIrecFuncResult SWIrecInit(const wchar_t *uri);

where SWIrecFuncResult is effectively an int.

The stack trace looks like the native code is attempting to deserialize an object. Perhaps it's relying on some on-disk (db?) data which is set up differently (or not at all) on the linux system.

Agreed, but the libraries are designed for linux. (And we are using the recommended distro of RedHat.)

Something else that might be relevant is that the libs and JRE are 32bit, but the OS is 64bit. I'm not sure I'd expect a problem there, but I figured I should mention it.

Could be an issue if the native code is getting system resources based on a 64-bit setup rather than a 32-bit one. You can always run on a 32-bit OS or virtual machine to make sure.

We tried a 32-bit system this morning, exact same crash.

Thanks again for the reply! Any other ideas you might have are welcome.

- Mark

On Thu, Jun 4, 2009 at 6:47 PM, Timothy Wall <twal...@dev.java.net> wrote: If you're running with jna.protected=true, you'll need to preload libjsig.so, e.g.

LD_PRELOAD=/path/to/libjsig.so java {java program args}

You have a single entry point, SWIrecInit(), which presumably expects a wchar_t* argument. On linux, wchar_t is 4 bytes by default, although you should check your library's documentation since it's possible to force a difference size. If it's expecting a char* argument and the windows version expecting wchar_t*, then you'll need to optionally use a type mapper on the windows version.

Apparently your third-party library could do more thorough error checking, since it looks like it's dereferencing a NULL pointer.

Given the simple entry point, the problem is more likely environmental than anything to do with the JNA mapping itself (assuming the mapping is correct -- you didn't provide a C prototype). LD_LIBRARY_PATH will likely be different between a C program and a java program (java adjusts the value and may fork a new process to ensure the path includes its own paths).

On Jun 4, 2009, at 8:00 PM, Mark Click wrote:

Hello!

I have a puzzling problem I'm hoping someone can help with! I've searched the archives and the googles but no luck.

I'm working with a set of commercial libraries in both Windows and Linux. I have a C test program and Java/JNA test program. Both work in Windows, but only the C test program works in Linux. The JNA code works _great_ in Windows, but it SIGSEGVs in Linux, in the native code. Everything else about the two installations is otherwise identical as far as I can tell, and we've tried a fair amount of obvious things (permissions, paths, etc) that are usually cause cross platform problems. It's so puzzling that the C test program works in Linux, but JNA accessing the same libraries doesn't.

If you want more detail, I've attached a dump of the crash. If you have any ideas, no matter how far fetched, I'd love to hear them!

- Mark < dump .txt

To unsubscribe, e-mail: user...@jna.dev.java.net For additional commands, e-mail: user...@jna.dev.java.net