JNI problem on Solaris 9

[Paul Gammon]

Hello,

I have a JNI problem on Solaris 9 that doesn't appear on Solaris 8. After a
process of trial
and error I have found that linking a native library with (-lmalloc) causes
a Unix signal
to be thrown within the JVM producing the following output

Test.main(): 1
libtest_r: Java_Test_testMethod(): 1
libtest_r: Java_Test_testMethod(): 2
libtest_r: Java_Test_testMethod(): 3
Test.main(): 2

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0xff2c34cc
Function name=realloc
Library=/usr/lib/libc.so.1

Cannot obtain thread information

Dynamic libraries:
0x10000 /usr/bin/../java/bin/../bin/sparc/native_threads/java
0xfe970000 /usr/lib/libmalloc.so.1
0xff370000 /usr/lib/libthread.so.1
0xff3a0000 /usr/lib/libdl.so.1
0xff280000 /usr/lib/libc.so.1
0xff350000 /usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1
0xfee80000 /usr/j2se/jre/lib/sparc/client/libjvm.so
0xff240000 /usr/lib/libCrun.so.1
0xfee60000 /usr/lib/libsocket.so.1
0xfed80000 /usr/lib/libnsl.so.1
0xfed50000 /usr/lib/libm.so.1
0xff360000 /usr/lib/libw.so.1
0xfee40000 /usr/lib/libmp.so.2
0xfed30000 /usr/lib/librt.so.1
0xfed10000 /usr/lib/libaio.so.1
0xfecf0000 /usr/lib/libmd5.so.1
0xfecc0000 /usr/platform/SUNW,UltraAX-i2/lib/libmd5_psr.so.1
0xfec90000 /usr/j2se/jre/lib/sparc/native_threads/libhpi.so
0xfec60000 /usr/j2se/jre/lib/sparc/libverify.so
0xfec10000 /usr/j2se/jre/lib/sparc/libjava.so
0xfebe0000 /usr/j2se/jre/lib/sparc/libzip.so
0xfea50000 /usr/lib/locale/en_GB.ISO8859-1/en_GB.ISO8859-1.so.2
0xfe990000 /export/home/reims/libtest_r.so
0xfe950000 /usr/lib/libpthread.so.1

The code fragements and test script below should duplicate the problem. Is
this a build
issue or a problem within Solaris 9 ? Are there any system patches that we
could apply ?

Regards

Paul Gammon

/*
* Test.java
*/

public class Test
{
static {
System.loadLibrary("test_r");
}

public static void main(String[] args) {
System.err.println("Test.main(): 1");
testMethod();
System.err.println("Test.main(): 2");
}

public static native void testMethod();
}

/*
* test.cpp
*/

#include <stdlib.h>
#include <stdio.h>
#include "Test.h"

JNIEXPORT void JNICALL Java_Test_testMethod(

JNIEnv* env,
jclass jcls)

{
fprintf(stderr, "libtest_r: Java_Test_testMethod(): 1\n");
void* p = calloc(1000, 1);
fprintf(stderr, "libtest_r: Java_Test_testMethod(): 2\n");
free(p);
fprintf(stderr, "libtest_r: Java_Test_testMethod(): 3\n");
}

/*
* makefile
*/

MODULE = test
OBJECTS = $(MODULE).o
LIBRARY = lib$(MODULE)_r.so
CPP_COMPILER = CC
CPP_COMPILER_FLAGS = -c -g -I$(JAVA_HOME)/include \
-I$(JAVA_HOME)/include/solaris -D_LIBTHREADED_ -DTHREADED \
-D_POSIX_PTHREAD_SEMANTICS -D__SOLARIS__ \
-features=no%conststrings -DSUN -D_UNIXDEFS_ -D_POSIX_SOURCE \
-D__EXTENSIONS__ -DMOTIF12_HEADERS
CPP_LINKER = CC
CPP_LINKER_FLAGS = -mt -KPIC -G -o
CPP_LIBRARIES
= -lm -lw -lc -lmalloc -lCstd -lCrun -lcx -lpthread -ljava -ljvm -lrt

..SUFFIXES: .h .hpp .c .cpp .o

all: $(LIBRARY)

$(LIBRARY): $(OBJECTS)
$(CPP_LINKER) $(CPP_LINKER_FLAGS) $(LIBRARY) $? $(CPP_LIBRARIES)

..cpp.o:
$(CPP_COMPILER) $(CPP_COMPILER_FLAGS) $<

/*
* do_test test script
*/

#!/bin/ksh

export JAVA_HOME=/usr/java1.3
export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
export CLASSPATH=.:$CLASSPATH
export PATH=$JAVA_HOME/bin:$PATH

javac Test.java
javah -jni Test
make
java Test

 

[Andrew Tyson]

Hello,

I have a JNI problem on Solaris 9 that doesn't appear on Solaris 8. After

a

Does the S9 machine have the latest patches required by the VM ( available
from sunsolve.sun.com)?
You might want to check the VM version running in each environment.
I presume that you are using the same VM on both machines, if so you
may wish to check if there is a more recent version of the VM in question.

HTH
Andrew

 

[Thomas Maslen]

I have a JNI problem on Solaris 9 that doesn't appear on Solaris 8. After a
process of trial
and error I have found that linking a native library with (-lmalloc) causes
a Unix signal
to be thrown within the JVM producing the following output

Er, why are you linking with libmalloc?

Offhand it seems like a possibly reasonable thing to do if you were linking
a complete executable where you control all the pieces, but a bad thing to
do if you are linking a shared object that's meant to play nice in some other
executable (particularly if that executable is the JVM).


Thomas Maslen
(e-mail address removed)

 

[Paul Gammon]

In <[email protected]> "Paul Gammon"

Er, why are you linking with libmalloc?

Offhand it seems like a possibly reasonable thing to do if you were linking
a complete executable where you control all the pieces, but a bad thing to
do if you are linking a shared object that's meant to play nice in some other
executable (particularly if that executable is the JVM).


Thomas Maslen
(e-mail address removed)

We use mallinfo() for diagnostics.