JVM crashes: Native method, JNI

[Abhishek Singh]

Hi!

I've got the jvm crashing when it calls native methods via the JNI.
The same native method run without a glitch in "pure" C. So there is
no bug in the native method, I suppose. What is more interesting
is that the same java program with the same native interface runs fine
using gij (from gnu) too!


$ java -version
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)

The native methods are in C. Compiled using gcc.
$ gcc -v

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --host=i386-redhat-linux --with-system-zlib
--enable-__cxa_atexit
Thread model: posix
gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)

The machine is P4 on Red hat linux 8.0
$ uname -a
Linux vanee.mlaproxy.iitk.ac.in 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT
2002 i686 i686 i386 GNU/Linux

The error message is
An unexpected exception has been detected in native code outside the
VM.
Unexpected Signal : 11 occurred at PC=0x4CDBEDA3
Function=Java_Medico_Producer_vanee+0x2B3
Library=/home/asingh/Java/medico/develop/Source/libnativelib.so

Current Java thread:
at Medico.Producer.vanee(Native Method)
at Medico.Producer.run(Producer.java:18)

If you are interested, I can also post the dyanamic libraries.

Any help is appreciated. Please cc me a copy at (e-mail address removed)

Thanks,
Abhishek.

 

[Gordon Beaton]

I've got the jvm crashing when it calls native methods via the JNI.
The same native method run without a glitch in "pure" C. So there is
no bug in the native method, I suppose. What is more interesting is
that the same java program with the same native interface runs fine
using gij (from gnu) too!

Most likely there *is* a bug in the native method. The fact that it
seems to work in other situations means nothing really.

If there isn't too much code, post it. In particular the function
mentioned in the error message (and the call path leading to it).

/gordon

 

[Nigel Wade]

Hi!

I've got the jvm crashing when it calls native methods via the JNI.
The same native method run without a glitch in "pure" C. So there is
no bug in the native method, I suppose. What is more interesting
is that the same java program with the same native interface runs fine
using gij (from gnu) too!


$ java -version
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)

The native methods are in C. Compiled using gcc.
$ gcc -v

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --host=i386-redhat-linux --with-system-zlib
--enable-__cxa_atexit
Thread model: posix
gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)

The machine is P4 on Red hat linux 8.0
$ uname -a
Linux vanee.mlaproxy.iitk.ac.in 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT
2002 i686 i686 i386 GNU/Linux

The error message is
An unexpected exception has been detected in native code outside the
VM.
Unexpected Signal : 11 occurred at PC=0x4CDBEDA3
Function=Java_Medico_Producer_vanee+0x2B3
Library=/home/asingh/Java/medico/develop/Source/libnativelib.so

Current Java thread:
at Medico.Producer.vanee(Native Method)
at Medico.Producer.run(Producer.java:18)

If you are interested, I can also post the dyanamic libraries.

Any help is appreciated. Please cc me a copy at (e-mail address removed)

Thanks,
Abhishek.

Well signal 11 is a seg. fault. That means it's tried to access an illegal
memory address, or a valid address in an illegal way i.e. it's tried to
access a segment it doesn't own or does not exist, or it has tried to write
to a read-only segment. Either there's a bug in the native method, or it
has been passed an illegal address somewhere.

You'd need to look and see what the C code was trying to do at the time, and
where it derived the faulty address from.